On Wed, Dec 16, 2009 at 9:55 AM, Robin Berjon <[email protected]> wrote:
> Hi Jonas,
>
> On Dec 10, 2009, at 19:42 , Jonas Sicking wrote:
>> On Tue, Dec 8, 2009 at 9:03 AM, Robin Berjon <[email protected]> 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
