Re: HTML5 File

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:29:09 UTC