W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: HTML5 File

From: イアンフェッティ <ifette@google.com>
Date: Wed, 2 Jun 2010 13:18:15 -0700
Message-ID: <AANLkTinqaNA2FAH3tLAGFhd49BHSx4YA4m2vL2aujAmO@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Cristiano Sumariva <sumariva@gmail.com>, public-webapps@w3.org
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 20:18:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT