Makes sense to me. (Though I'm still not convinced of its usefulness). / Jonas
2010/6/2 Ian Fette (イアンフェッティ) <ife...@google.com>: > Also, for the sake of keeping things together, when we move this over we > should probably move FileSystem over as well. > -Ian > > On Wed, Jun 2, 2010 at 3:27 PM, Ian Fette (イアンフェッティ) <ife...@google.com> > wrote: >> >> I'm reaching out to some W3C team contacts to figure out logistics. >> -Ian >> >> On Wed, Jun 2, 2010 at 2:02 PM, Jonas Sicking <jo...@sicking.cc> wrote: >>> >>> I don't know who makes these decisions, but I'd imagine the editor >>> holds a certain amount of sway. I'd imagine that it would get a lot >>> more review and attention from browser companies on WebApps. Apple >>> isn't on DAP at all, and everyone from mozilla that works on related >>> APIs are not on the DAP list (I don't have time to join another list, >>> I imagine the same holds true for others though I'm not sure). >>> >>> / Jonas >>> >>> 2010/6/2 Ian Fette (イアンフェッティ) <ife...@google.com>: >>> > I whole-heartedly agree, and have said as much in the past, both on >>> > public >>> > MLs and to various W3C team contacts. >>> > -Ian >>> > >>> > On Wed, Jun 2, 2010 at 1:14 PM, Jonas Sicking <jo...@sicking.cc> wrote: >>> >> >>> >> It keeps seeming to me that moving the file-writer spec to WebApps >>> >> would make much more sense... >>> >> >>> >> / Jonas >>> >> >>> >> 2010/6/2 Ian Fette (イアンフェッティ) <ife...@google.com>: >>> >> > http://www.w3.org/TR/file-writer-api/ >>> >> > >>> >> > On Tue, Jun 1, 2010 at 8:18 AM, Cristiano Sumariva >>> >> > <sumar...@gmail.com> >>> >> > wrote: >>> >> >> >>> >> >> I have been reading the specification on file section. >>> >> >> I would like to ask why not propose that File interface allow a >>> >> >> create >>> >> >> method to let user save data for his use? >>> >> >> >>> >> >> Resume: >>> >> >> >>> >> >> Interface File extends Blob >>> >> >> { >>> >> >> attribute unsigned long long currentPosition; >>> >> >> readonly attribute signed long long deviceSpaceLeft; >>> >> >> readonly attribute unsigned short machineEndian; >>> >> >> const unsigned short BIG_ENDIAN = 1; >>> >> >> const unsigned short LITTLE_ENDIAN = 0; >>> >> >> const unsigned short UNKNOW_SIZE = -1; >>> >> >> File create( ); >>> >> >> File createBynary(); >>> >> >> signed long write( in DOMString text, optional in unsigned long >>> >> >> long >>> >> >> position, optional DOMString fromCharset ) >>> >> >> signed long writeBinary( in DOMString blob, optional in >>> >> >> unsgined >>> >> >> long >>> >> >> long position ) >>> >> >> } >>> >> >> >>> >> >> An web application in this way could for example create a list of >>> >> >> computed >>> >> >> values and allow the user to save the contents to a file without >>> >> >> need >>> >> >> send >>> >> >> data for the server to pack contents and issue a file download >>> >> >> request >>> >> >> to >>> >> >> client. >>> >> >> Or implement an image editor in javascript code using the new >>> >> >> canvas >>> >> >> element and allow read, create, store to be done without server >>> >> >> assistance. >>> >> >> Work on offline mode too. >>> >> >> >>> >> >> About security on file creation: >>> >> >> When the web application request this operation File.create() the >>> >> >> browser >>> >> >> could launch a confirm( save file) dialog so the user only could >>> >> >> grant >>> >> >> the >>> >> >> rights for a file creation. >>> >> >> This dialog( modal? ) would manage file overwrite and more stuff >>> >> >> related >>> >> >> to file access( user may write at selected folder ) so that >>> >> >> returned >>> >> >> file >>> >> >> reference could be overwritten by client script without trouble. >>> >> >> The return type for that function could be string or a File object. >>> >> >> An empty name value or Exception signal that user denied the >>> >> >> request. >>> >> >> >>> >> >> If there is concerns about absolute file paths been exposed to >>> >> >> javascript >>> >> >> code >>> >> >> then the File.create method could return a boolean status >>> >> >> indicating >>> >> >> that >>> >> >> the object is ready to write( true ) and no file paths would be >>> >> >> exposed >>> >> >> at >>> >> >> all. Or only the basename of file without path information. >>> >> >> >>> >> >> For differences between binary and text modes a second method call >>> >> >> could >>> >> >> signal File object that the new file should be used on binary mode: >>> >> >> File.createBinary() - same behavior like File.create above but in >>> >> >> binary >>> >> >> mode. >>> >> >> >>> >> >> The file object could have some read only properties for device >>> >> >> space >>> >> >> control: >>> >> >> For example: >>> >> >> readonly File.deviceSpaceLeft - so when script is making write >>> >> >> calls >>> >> >> to >>> >> >> file if would know in advance if space still available for writing. >>> >> >> Or >>> >> >> application could launch a warn that no space left to save data. If >>> >> >> the >>> >> >> implementer do not know how to tell the space left then a >>> >> >> File.UNKNOWSIZE >>> >> >> value should be returned. >>> >> >> >>> >> >> double File.currentPosition - traditional File pointer to know >>> >> >> where in >>> >> >> the file the client is writing to. Since size is readonly changing >>> >> >> this >>> >> >> property move the current position in file cursor. Negative values >>> >> >> are >>> >> >> invalid and ignored. A positive value greater then current value >>> >> >> increase >>> >> >> the file size to the new size( doing this at begin could be a way >>> >> >> to >>> >> >> reserve >>> >> >> space needed on disk at once since the file would grow to this >>> >> >> current >>> >> >> size, >>> >> >> and help filesystem reduce fragmentation ). Changing this attribute >>> >> >> on >>> >> >> a >>> >> >> file opened for read does nothing and is ignored. The size >>> >> >> atrribute >>> >> >> should >>> >> >> reflect the new size confirming that file size increased. >>> >> >> >>> >> >> May cause UI hangs on large move requests. >>> >> >> User agents may show on the create dialog a max file size allowed >>> >> >> to be >>> >> >> created making impossible to script consume all space left on >>> >> >> device. >>> >> >> >>> >> >> readonly boolean File.machineEndian - binary files on target >>> >> >> machine >>> >> >> could >>> >> >> have data stored in different formats then the script reading would >>> >> >> expect. >>> >> >> This flag would tell the script how to pack unpack data to be used >>> >> >> on >>> >> >> client >>> >> >> machine. >>> >> >> >>> >> >> Cristiano >>> >> >> >>> >> >> >>> >> > >>> >> > >>> > >>> > >> > >
