Re: The most basic File API use case

On Wed, Dec 16, 2009 at 11:58 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.

I think progress events are reasonable for anything that might take a
long time.  If you're loading/saving a large movie file from/to a
network filesystem, it's good to be able to tell the difference
between the action being hung and the write making slow progress.
This way you can show the user a progress bar.

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

If you're able to generate the data to be saved programmatically, you
can do write a byte at a time, and you can generate it after asking
for permission to save the file.  I don't think it makes sense to run
a scanner on it before it hits the disk, so I don't think there's any
security issue here that's not also there in any case where you can
write arbitrary files to the disk.

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

Abort() is useful if the user gets sick of waiting, or realizes he's
forgotten to add the caption track, or changes his mind as to where to
save the file.  I don't see anything wrong with attempting to delete
the partially-written data on abort, although that's only possible if
your writing API is pretty simple [i.e. just a single write of an
entire file].

I've put together a new proposal that rolls in a lot of the above
feedback.  I posted it [1] and an associated proposal for directory
access [2] today to the DAP working group.  I'd appreciate it if folks
would wander over to DAP and take a look; I look forward to your
feedback.

Thanks,

     Eric

[1] http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0228.html
[2] http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0229.html

Received on Saturday, 30 January 2010 00:27:40 UTC