> > The current File API draft lets a web app to read the file, but there seems >> to be no easy way for a web app to construct an arbitrary binary file and >> trigger a SaveAs/download dialog, with the file name suggested by the app. >> >> > > I agree with this use case being a logical next step. > > >> > As far as Group 0 goes, I agree and think we'll need: > > 1. A script initiated SaveAs mechanism. > > 2. Something like BlobBuilder (as you point out). > > Next steps can evolve from these. > > May I suggest then a specific implementation, in order to move the process forward a bit. All names/signatures/behaviors below are intended to start the discussion only, and not as a draft or anything formal. :)
Based on [1] <http://www.w3.org/TR/2009/WD-FileAPI-20091117/> and [2]<http://code.google.com/apis/gears/api_blobbuilder.html>, we can have two interfaces introduced into the File API specification: BlobBuilder: based on Google Gears [2]<http://code.google.com/apis/gears/api_blobbuilder.html> . interface BlobBuilder { void appendText( in DOMString text, [Optional] in DOMString encoding ); void appendBinaryString( in DOMString text ); /* same as in FileReader */ void appendByte( in long val ); /* if val is not in the [0-255] range, throws an exception */ void appendBlob( in Blob blob ); /* this method can probably be asynchronous, but IMHO this is not necessary at the "Group 0 use case" stage */ Blob getBlob(); } FileWriter: interface FileWriter { /* shows the SaveAs dialog, returns the saved File or null if error/canceled by the user */ /* can be made synchronous (modal) or asynchronous, I'm not sure at the moment which approach is better */ File saveBlobAsFilePrompt( in Blob blob, in [Optional] DOMString suggestedFileName ); /* synchronous/modal variant; asynchronous will return nothing and have events */ } Later FileWriter can be expanded to cover other use cases. Thanks, Peter [1] http://www.w3.org/TR/2009/WD-FileAPI-20091117/ [2] http://code.google.com/apis/gears/api_blobbuilder.html