Re: The most basic File API use case

On Wed, Dec 16, 2009 at 9:55 AM, Robin Berjon <robin@berjon.com> wrote:
> Hi Jonas,
>
> On Dec 10, 2009, at 19:42 , Jonas Sicking wrote:
>> On Tue, Dec 8, 2009 at 9:03 AM, Robin Berjon <robin@berjon.com> wrote:
>>> [Constructor(DOMString mediaType, DOMString fileName)]
>>> interface FileWriter {
>>>    // saving operations
>>>    void save (DOMString content, optional DOMString encoding, optional DOMString endings);
>>>    void save (Blob data);
>>
>> Hmm.. I'm not entirely convinced that it's worth having the first of
>> these two methods. You're already up to two optional arguments, and
>> more might be needed (such as if to include a BOM or not). It might be
>> simpler to simply require people to create Blobs and then save that
>> Blob.
>
> I could live with other options but there are things that are quite specific to writing text, amongst them at the very least using the same encoding throughout (which is clumsy if you have to append several times to a blob and specify it every time. I thought of having a TextBlob that could take encoding, line endings, BOM, etc. as parameters to its constructor and then passing that to save() but I'm not entirely sure that what we get from the change is really valuable.

But if to need to append several times then you can't use the above
interface anyway, can you?

> How about:
>
>  void save (DOMString content, TextOptions options);
>
> where the second argument would be an object literal that could capture all of this?
>
> Another option would be:
>
>  Blob textToBlob (DOMString content, TextOptions options);

I don't really see that this would be much more convenient than:

bb = new BlobBuilder;
bb.appendText(myString, ...);
filewriter.save(bb.getBlob());



> possibly on another interface but again I'm not sure what that gains us. Do we have use cases for textual blobs being used elsewhere? If yes, then I'm thinking:
>
> interface TextBlobBuilder {
>    attribute DOMString content;
>    attribute DOMString encoding;
>    attribute DOMString endings;
>    attribute boolean BOM;
>    Blob generateBlob ();
> };
>
> Thoughts?

I don't think I understand this proposal. Can you elaborate, or show
code that would use this?

>>>    // abort the save
>>>    void abort();
>>>
>>>    // state codes
>>>    const unsigned short INITIAL = 0;
>>>    const unsigned short WRITING = 1;
>>>    const unsigned short DONE    = 2;
>>>    readonly attribute unsigned short readyState;
>>>
>>>    // error, same as FileReader but with some additions
>>>    readonly attribute FileError error;
>>>
>>>    // event handler attributes
>>>    attribute Function onloadstart;
>>>    attribute Function onprogress;
>>>    attribute Function onload;
>>>    attribute Function onabort;
>>>    attribute Function onerror;
>>>    attribute Function onloadend;
>>
>> I think most of this is overkill. What is the use case for progress
>> events here? I.e. why does the page need to know how much data has
>> been written? And why would you want to abort writing the file?
>
> Well, if there are use cases for reading, the same apply for writing. If you build a large file (e.g. for graphics editing) and save it to a slow storage (e.g. network drive, SIM) then it could take a very measurable amount of time (this happens in Photoshop even on powerful computers), and if it does you probably want to inform the user and to provide her with a way to give up.
>
> This is essentially a mirror of FileReader; I think it makes sense and not just for consistency.

Well.. I'm still not convinced that anyone will actually use progress
events for reading files.

The idea of allowing the page to start a write and then aborting it
scares me a little. And I'm not sure I see the use case. For example I
could imagine implementations running a virus scan on the data before
bringing up the "save as" dialog, or checking if the page is trying to
write an executable. In these cases a call to abort() could then cause
slightly different data to be written to disc than was originally
checked.

I guess removing the abort() call would make me feel easier about
this. Or specifying that a call to abort() causes all the data written
so far to be deleted.

My question still remains what the use case for abort() is though.

/ Jonas

Received on Wednesday, 16 December 2009 19:59:45 UTC