HTML5 File

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