Re: The most basic File API use case

Hi Robin,

Glad to see this initial draft!

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.

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


> Then we have a WritableBlob. I'm not married to the name, I just liked the approach of having a single object which both contains the data and does the manipulation, as opposed to the builder object from which you get the content when you're done. The level of indirection didn't seem necessary, but maybe I missed something. As I said above, we can have more options as in your BlobBuilder to add content into it, and we don't have to use overloading if people don't like it (or if it doesn't scale). If we do stick to overloading I wouldn't be adverse to adding Constructor(Blob blob) and Constructor(octet val).
>
> [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);

Also, this doesn't allow creating Files with a specific name, for use
in other APIs.

Instead I would propose an API like:

[Constructor]
interface BlobGenerator {
    // Methods to add data to the blob
    void put (Blob blob);
    void put (octet val);
    void put (DOMString string, optional DOMString encoding);

   // Methods to extract a usable object
   Blob generateBlob();
   File generateFile(DOMString name, optional DOMString type);
};

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

/ Jonas

Received on Thursday, 10 December 2009 18:42:55 UTC