Re: HTML5 File

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 21:03:15 UTC