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

Re: HTML5 File

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 2 Jun 2010 15:37:45 -0700
Message-ID: <AANLkTin1PS-nXBRjB77pJC98K1H3Uz1fpyZ8VVLdATPk@mail.gmail.com>
To: ifette@google.com
Cc: Cristiano Sumariva <sumariva@gmail.com>, public-webapps@w3.org
Makes sense to me. (Though I'm still not convinced of its usefulness).

/ Jonas

2010/6/2 Ian Fette (イアンフェッティ) <ifette@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 (イアンフェッティ) <ifette@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 <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:38:38 GMT

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