On Wed, Dec 16, 2009 at 9:55 AM, Robin Berjon <ro...@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 <ro...@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