Re: The most basic File API use case

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.

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);

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?

>>    // 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.

>> [Constructor]
>> interface WritableBlob : Blob {
>>    void put (Blob blob);
>>    void put (octet val);
>>    void put (DOMString string, optional DOMString encoding);
>> };
> 
> I'd prefer the concept of a "Blob factory" than mutable blobs. With
> mutable blobs we (or at least the implementation) has to worry about
> things like what if the blob mutates in the middle of being read or
> written. For example if you do:
> 
> b = new WriteableBlob();
> worker.postMessage(b);
> b.put(14);

Heh, so basically you don't think that it could take long enough that progress events may be needed but you do fear that it may be slow enough that people could change the objects as they're being processed? :)

You make a good argument though, I'll re-switch the approach to use a builder.

> Further, I would probably rename 'put' to 'append' to make it more
> clear that it doesn't overwrite data appended so far.

My initial idea was that put() could also write in other locations if we had seek(), but no one else seems to think this might be useful so I'm happy to switch to append().

I'll produce an updated draft soon.

-- 
Robin Berjon - http://berjon.com/

Received on Wednesday, 16 December 2009 17:56:23 UTC