Re: HTML5 File

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
>
>
>