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 15:27:06 -0700
Message-ID: <AANLkTim4-3MuW01zqpLfL7HtnUqy-nL9KmpSmpGAGHyx@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Cristiano Sumariva <sumariva@gmail.com>, public-webapps@w3.org
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 GMT

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