- From: イアンフェッティ <ifette@google.com>
- Date: Wed, 2 Jun 2010 15:27:06 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Cristiano Sumariva <sumariva@gmail.com>, public-webapps@w3.org
- Message-ID: <AANLkTim4-3MuW01zqpLfL7HtnUqy-nL9KmpSmpGAGHyx@mail.gmail.com>
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 <jonas@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 (イアンフェッティ) <ifette@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 <jonas@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 (イアンフェッティ) <ifette@google.com>: > >> > http://www.w3.org/TR/file-writer-api/ > >> > > >> > On Tue, Jun 1, 2010 at 8:18 AM, Cristiano Sumariva < > sumariva@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 > >> >> > >> >> > >> > > >> > > > > > >
Received on Wednesday, 2 June 2010 22:27:37 UTC