Re: HTML5 File
On Fri, Jun 4, 2010 at 5:16 PM, Ian Fette (イアンフェッティ) ife...@google.com wrote: On Fri, Jun 4, 2010 at 8:53 AM, Robin Berjon ro...@berjon.com wrote: On Jun 3, 2010, at 19:29 , Ian Fette (イアンフェッティ) wrote: Actually, I should take that back. Some of the device specs are definitely relevant Right, and some of your colleagues just submitted Powerbox there, which seems like a non-negligible chunk of work to me ;-) To be clear, Chrome-team is not involved in powerbox, nor is android team to the best of my knowledge. Just to confirm: that is correct, Android is not involved in Powerbox in any way. Thanks, Andrei
Re: HTML5 File
On Jun 4, 2010, at 18:16 , Ian Fette (イアンフェッティ) wrote: I recall pushing strongly to correct that at TPAC in san jose. I don't think it's purely historical. Well, it's historical in the sense that that is the agreement that we reached when the discussion was last on the table (which was months before the Santa Clara meeting). It doesn't mean that it can't be reopened — I'm just trying to provide sufficient context that it can be handled sanely. -- Robin Berjon - http://berjon.com/
Re: HTML5 File
On Jun 4, 2010, at 22:36 , Arun Ranganathan wrote: On 6/3/10 4:13 AM, Robin Berjon wrote: Decisions of what is in scope for a WG are made by the members (i.e. you) when a WG is created. When DAP was created, people felt rather strongly (personally, I disagreed, I know that Arun had similar concerns) that adding deliverables to WebApps would be a bad idea as it already had many, and because there was already a lot of traffic on its list. To be clear, I was *very much in favor* of FileAPI-related items being added to WebApps, but was less enthusiastic about Widget-related items or the Web SQL Database item. David Baron, Mozilla's Advisory Committee Representative, made this stance public in a blog post I know, but that's from two months ago, not from last year (which is what I was referring to). This language in my opinion certainly includes FileWriter and anything FileSystem related, and moving from DAP -- WebApps should NOT warrant a charter review. This language was approved by all members. Moving to file-related APIs to WebApps (from DAP) has the following advantages: 1. Wide implementor review. My concern is that not ALL browser vendors are members of DAP; ALL browser vendors are members of WebApps. Moreover, since a charter review/amendment doesn't seem necessary, given the inclusive language around file APIs, I think there is a strong case to be made for this work to proceed in WebApps. 2. Family of specifications living together. Changes to FileAPI impace XHR (at least with the introduction of ArrayBuffers); Blob is useful in other areas, and FileWriter proposes a BlobBuilder. Those are certainly good arguments. My sole concern is that they're not really geared towards solving problems (see more below). Right now they're getting implementor review, and they're being synchronised where they need to. This was discussed publicly in the months leading up to DAP being chartered (including with involvement from Mozilla participants) but the eventual balance became the one we have today. I think (though I do not know for sure) that one factor in this was the fact that the File API which is so nicely alive today had, while DAP was being chartered, not been updated since 2006 and was still called the File Upload API. This is true. But, I see no impediment to changing this for the better, given the existing charter language on WebApps. Do you, or does anyone that is a member of the DAP WG? Likewise, does any member of the WebApps WG object strongly? Speaking personally, with all my hats off, I really, really don't care either way. As far as I'm concerned, both File Writer and File Directory have 1) an active editor who's going a really good job and 2) since any major change is discussed on WebApps anyway a solid process of community review with strong implementer involvement. It doesn't seem broken, and as a consequence, call me lazy but that makes me disinclined to want to fix it. I haven't taken DAP's pulse on this, but if a single person doesn't like it and throws a tantrum, we have a bigger problem after the fix than before. So if you're really adamant I can take it to DAP, but it would be helpful to have better arguments than things could go wrong, even though everything's worked out fine so far or it would be neater :) The only thing that tends to incline me towards a transfer is the fact that I can't seem to find a single comment on Eric's drafts from someone in DAP who isn't also in WebApps. But again, that's more in the neatness domain. And of course DAP's an open house, you can raise the issue there directly! -- Robin Berjon - http://berjon.com/
Transferring File* to WebApps (was Re: HTML5 File)
Thanks Eric for bringing this up here. On Jun 5, 2010, at 00:21 , Eric Uhrhane wrote: First of all, I think this discussion should include DAP [+CC]. DAP folks, this discussion started at http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0886.html. My take is that I've gotten lots of useful feedback on FileWriter on both webapps and DAP. However, recently most of the FileWriter discussion has been on webapps, mainly as asides on other topics, and the last time I sent a request for comments to DAP it received no responses. I would like to see both specs be officially discussed on webapps. I think we really need input from all the browser companies in order to make a solid API, and in order to produce something that everyone's eager to implement. If they won't come to DAP, then this part should come to them. I'd also appreciate it if DAP folks who've contributed to the specs so far continued to be involved. I don't know what the logistics of that would be. The specs are clearly within the charters of both groups. And of course several folks have been popping back and forth between lists anyway. I'm not really too bothered about the exact form of the discussion and publication, as long as we get everyone involved. DAP people: I expect that there will be some coordination between the chairs of DAP and WebApps as well as the W3C tema on this topic circa the end of the week. It would be most useful if you could make your opinions (if any) known quickly so that we can make an informed decision. Thanks! -- Robin Berjon - http://berjon.com/
Re: HTML5 File
On Jun 3, 2010, at 19:29 , Ian Fette (イアンフェッティ) wrote: Actually, I should take that back. Some of the device specs are definitely relevant Right, and some of your colleagues just submitted Powerbox there, which seems like a non-negligible chunk of work to me ;-) though I have concerns about the direction they are heading I regularly hear people having concerns about the direction in which DAP specs are heading. The shame is, they never seem to want to provide any details. Either way though, it seems strange for the filesystem apis to be split. As I said, it's historical, and due to no one pushing strong to correct that during chartering. Speaking personally, I don't really care much either way. -- Robin Berjon - http://berjon.com/
Re: HTML5 File
On Fri, Jun 4, 2010 at 8:53 AM, Robin Berjon ro...@berjon.com wrote: On Jun 3, 2010, at 19:29 , Ian Fette (イアンフェッティ) wrote: Actually, I should take that back. Some of the device specs are definitely relevant Right, and some of your colleagues just submitted Powerbox there, which seems like a non-negligible chunk of work to me ;-) To be clear, Chrome-team is not involved in powerbox, nor is android team to the best of my knowledge. though I have concerns about the direction they are heading I regularly hear people having concerns about the direction in which DAP specs are heading. The shame is, they never seem to want to provide any details. Either way though, it seems strange for the filesystem apis to be split. As I said, it's historical, and due to no one pushing strong to correct that during chartering. Speaking personally, I don't really care much either way. I recall pushing strongly to correct that at TPAC in san jose. I don't think it's purely historical. -- Robin Berjon - http://berjon.com/
Re: HTML5 File
On 6/3/10 4:13 AM, Robin Berjon wrote: On Jun 2, 2010, at 23:02 , Jonas Sicking wrote: I don't know who makes these decisions, but I'd imagine the editor holds a certain amount of sway. Decisions of what is in scope for a WG are made by the members (i.e. you) when a WG is created. When DAP was created, people felt rather strongly (personally, I disagreed, I know that Arun had similar concerns) that adding deliverables to WebApps would be a bad idea as it already had many, and because there was already a lot of traffic on its list. To be clear, I was *very much in favor* of FileAPI-related items being added to WebApps, but was less enthusiastic about Widget-related items or the Web SQL Database item. David Baron, Mozilla's Advisory Committee Representative, made this stance public in a blog post: http://blog.mozilla.com/standards/2010/04/30/mozilla-at-w3c-review-of-web-applications-wg-charter/ I'll note that the current charter -- http://www.w3.org/2010/webapps/charter/ -- uses the following language when discussing File API: An API for representing file objects in web applications, as well as programmatically selecting them and accessing their data. This may include file writing and file system APIs. This replaces the File Upload specification. This language in my opinion certainly includes FileWriter and anything FileSystem related, and moving from DAP -- WebApps should NOT warrant a charter review. This language was approved by all members. Moving to file-related APIs to WebApps (from DAP) has the following advantages: 1. Wide implementor review. My concern is that not ALL browser vendors are members of DAP; ALL browser vendors are members of WebApps. Moreover, since a charter review/amendment doesn't seem necessary, given the inclusive language around file APIs, I think there is a strong case to be made for this work to proceed in WebApps. 2. Family of specifications living together. Changes to FileAPI impace XHR (at least with the introduction of ArrayBuffers); Blob is useful in other areas, and FileWriter proposes a BlobBuilder. This was discussed publicly in the months leading up to DAP being chartered (including with involvement from Mozilla participants) but the eventual balance became the one we have today. I think (though I do not know for sure) that one factor in this was the fact that the File API which is so nicely alive today had, while DAP was being chartered, not been updated since 2006 and was still called the File Upload API. This is true. But, I see no impediment to changing this for the better, given the existing charter language on WebApps. Do you, or does anyone that is a member of the DAP WG? Likewise, does any member of the WebApps WG object strongly? -- A*
Re: HTML5 File
Hey all--I'm sorry it's taken me so long to respond to this thread. I'm a little short on bandwidth right now, and that's likely going to get worse for at least a couple of weeks. First of all, I think this discussion should include DAP [+CC]. DAP folks, this discussion started at http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0886.html. My take is that I've gotten lots of useful feedback on FileWriter on both webapps and DAP. However, recently most of the FileWriter discussion has been on webapps, mainly as asides on other topics, and the last time I sent a request for comments to DAP it received no responses. I would like to see both specs be officially discussed on webapps. I think we really need input from all the browser companies in order to make a solid API, and in order to produce something that everyone's eager to implement. If they won't come to DAP, then this part should come to them. I'd also appreciate it if DAP folks who've contributed to the specs so far continued to be involved. I don't know what the logistics of that would be. The specs are clearly within the charters of both groups. And of course several folks have been popping back and forth between lists anyway. I'm not really too bothered about the exact form of the discussion and publication, as long as we get everyone involved. Thanks, Eric On Fri, Jun 4, 2010 at 1:36 PM, Arun Ranganathan a...@mozilla.com wrote: On 6/3/10 4:13 AM, Robin Berjon wrote: On Jun 2, 2010, at 23:02 , Jonas Sicking wrote: I don't know who makes these decisions, but I'd imagine the editor holds a certain amount of sway. Decisions of what is in scope for a WG are made by the members (i.e. you) when a WG is created. When DAP was created, people felt rather strongly (personally, I disagreed, I know that Arun had similar concerns) that adding deliverables to WebApps would be a bad idea as it already had many, and because there was already a lot of traffic on its list. To be clear, I was *very much in favor* of FileAPI-related items being added to WebApps, but was less enthusiastic about Widget-related items or the Web SQL Database item. David Baron, Mozilla's Advisory Committee Representative, made this stance public in a blog post: http://blog.mozilla.com/standards/2010/04/30/mozilla-at-w3c-review-of-web-applications-wg-charter/ I'll note that the current charter -- http://www.w3.org/2010/webapps/charter/ -- uses the following language when discussing File API: An API for representing file objects in web applications, as well as programmatically selecting them and accessing their data. This may include file writing and file system APIs. This replaces the File Upload specification. This language in my opinion certainly includes FileWriter and anything FileSystem related, and moving from DAP -- WebApps should NOT warrant a charter review. This language was approved by all members. Moving to file-related APIs to WebApps (from DAP) has the following advantages: 1. Wide implementor review. My concern is that not ALL browser vendors are members of DAP; ALL browser vendors are members of WebApps. Moreover, since a charter review/amendment doesn't seem necessary, given the inclusive language around file APIs, I think there is a strong case to be made for this work to proceed in WebApps. 2. Family of specifications living together. Changes to FileAPI impace XHR (at least with the introduction of ArrayBuffers); Blob is useful in other areas, and FileWriter proposes a BlobBuilder. This was discussed publicly in the months leading up to DAP being chartered (including with involvement from Mozilla participants) but the eventual balance became the one we have today. I think (though I do not know for sure) that one factor in this was the fact that the File API which is so nicely alive today had, while DAP was being chartered, not been updated since 2006 and was still called the File Upload API. This is true. But, I see no impediment to changing this for the better, given the existing charter language on WebApps. Do you, or does anyone that is a member of the DAP WG? Likewise, does any member of the WebApps WG object strongly? -- A*
Re: HTML5 File
On Jun 2, 2010, at 22:14 , Jonas Sicking wrote: It keeps seeming to me that moving the file-writer spec to WebApps would make much more sense... It's certainly a discussion that we can look into, but before we try to re-engineer everything I'd like to ask a stupid question: did the OP not find File Writer because it is owned by DAP and not WebApps, or simply because we've split writing off from reading, which no other FS-related API in the world does? Most of the rest of the tech world doesn't care which WG does what. In fact, most don't know that there exist such things as WebApps or DAP. The proportion of people who think it's just W3C doing HTML5 is likely very, very large. And I'm not convinced that that is necessarily a problem (I certainly find it to be much, much less of a problem than people chanting that W3C got it wrong but who've never showed up to send in a comment). So, should we choose to address the stated issue (which I'm not entirely convinced exists, but let's assume it does) which would be best? • To jump through all the hoops of rechartering two WGs? • To place a link on each document to the others? • To put the same links on the WGs' wikis and home pages? • To make public-webapps the official discussion venue for File *? • Several of the above? I'd be curious to hear from those who most feel that this is a problem to know if the simpler option(s) might not be better than the heavier one(s). -- Robin Berjon - http://berjon.com/
Re: HTML5 File
On Jun 2, 2010, at 23:02 , Jonas Sicking wrote: I don't know who makes these decisions, but I'd imagine the editor holds a certain amount of sway. Decisions of what is in scope for a WG are made by the members (i.e. you) when a WG is created. When DAP was created, people felt rather strongly (personally, I disagreed, I know that Arun had similar concerns) that adding deliverables to WebApps would be a bad idea as it already had many, and because there was already a lot of traffic on its list. This was discussed publicly in the months leading up to DAP being chartered (including with involvement from Mozilla participants) but the eventual balance became the one we have today. I think (though I do not know for sure) that one factor in this was the fact that the File API which is so nicely alive today had, while DAP was being chartered, not been updated since 2006 and was still called the File Upload API. I'm not saying that the above is good, I'm just answering your question :) I'd imagine that it would get a lot more review and attention from browser companies on WebApps. Well, technically, whenever there's an update or important question, it's discussed here anyway. Apple isn't on DAP at all Which makes one speculate whether IP issues might have weighed in the balanced to have DAP's deliverables be in a separate group. and everyone from mozilla that works on related APIs are not on the DAP list I think you mean not everyone rather than everyone are not. There are Mozilla people working on APIs that are on DAP. -- Robin Berjon - http://berjon.com/
Re: HTML5 File
Were it not for file* I, and perhaps Google as a whole, would likely leave DAP (though I cannot speak for everyone). Nothing else there is of interest to me right now. On Jun 3, 2010 4:13 AM, Robin Berjon ro...@berjon.com wrote: On Jun 2, 2010, at 23:02 , Jonas Sicking wrote: I don't know who makes these decisions, but I'd imagine the editor holds a certain amount of sway. Decisions of what is in scope for a WG are made by the members (i.e. you) when a WG is created. When DAP was created, people felt rather strongly (personally, I disagreed, I know that Arun had similar concerns) that adding deliverables to WebApps would be a bad idea as it already had many, and because there was already a lot of traffic on its list. This was discussed publicly in the months leading up to DAP being chartered (including with involvement from Mozilla participants) but the eventual balance became the one we have today. I think (though I do not know for sure) that one factor in this was the fact that the File API which is so nicely alive today had, while DAP was being chartered, not been updated since 2006 and was still called the File Upload API. I'm not saying that the above is good, I'm just answering your question :) I'd imagine that it would get a lot more review and attention from browser companies on WebApps. Well, technically, whenever there's an update or important question, it's discussed here anyway. Apple isn't on DAP at all Which makes one speculate whether IP issues might have weighed in the balanced to have DAP's deliverables be in a separate group. and everyone from mozilla that works on related APIs are not on the DAP list I think you mean not everyone rather than everyone are not. There are Mozilla people working on APIs that are on DAP. -- Robin Berjon - http://berjon.com/
Re: HTML5 File
Actually, I should take that back. Some of the device specs are definitely relevant, though I have concerns about the direction they are heading. Either way though, it seems strange for the filesystem apis to be split. On Thu, Jun 3, 2010 at 8:22 AM, Ian Fette (イアンフェッティ) ife...@google.comwrote: Were it not for file* I, and perhaps Google as a whole, would likely leave DAP (though I cannot speak for everyone). Nothing else there is of interest to me right now. On Jun 3, 2010 4:13 AM, Robin Berjon ro...@berjon.com wrote: On Jun 2, 2010, at 23:02 , Jonas Sicking wrote: I don't know who makes these decisions, but I'd imagine the editor holds a certain amount of sway. Decisions of what is in scope for a WG are made by the members (i.e. you) when a WG is created. When DAP was created, people felt rather strongly (personally, I disagreed, I know that Arun had similar concerns) that adding deliverables to WebApps would be a bad idea as it already had many, and because there was already a lot of traffic on its list. This was discussed publicly in the months leading up to DAP being chartered (including with involvement from Mozilla participants) but the eventual balance became the one we have today. I think (though I do not know for sure) that one factor in this was the fact that the File API which is so nicely alive today had, while DAP was being chartered, not been updated since 2006 and was still called the File Upload API. I'm not saying that the above is good, I'm just answering your question :) I'd imagine that it would get a lot more review and attention from browser companies on WebApps. Well, technically, whenever there's an update or important question, it's discussed here anyway. Apple isn't on DAP at all Which makes one speculate whether IP issues might have weighed in the balanced to have DAP's deliverables be in a separate group. and everyone from mozilla that works on related APIs are not on the DAP list I think you mean not everyone rather than everyone are not. There are Mozilla people working on APIs that are on DAP. -- Robin Berjon - http://berjon.com/
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
Re: HTML5 File
http://www.w3.org/TR/file-writer-api/
On Tue, Jun 1, 2010 at 8:18 AM, Cristiano Sumariva sumar...@gmail.comwrote:
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
Re: HTML5 File
It keeps seeming to me that moving the file-writer spec to WebApps
would make much more sense...
/ Jonas
2010/6/2 Ian Fette (イアンフェッティ) ife...@google.com:
http://www.w3.org/TR/file-writer-api/
On Tue, Jun 1, 2010 at 8:18 AM, Cristiano Sumariva sumar...@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
Re: HTML5 File
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 jo...@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 (イアンフェッティ) ife...@google.com:
http://www.w3.org/TR/file-writer-api/
On Tue, Jun 1, 2010 at 8:18 AM, Cristiano Sumariva sumar...@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
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 (イアンフェッティ) ife...@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 jo...@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 (イアンフェッティ) ife...@google.com:
http://www.w3.org/TR/file-writer-api/
On Tue, Jun 1, 2010 at 8:18 AM, Cristiano Sumariva sumar...@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
Re: HTML5 File
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 jo...@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 (イアンフェッティ) ife...@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 jo...@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 (イアンフェッティ) ife...@google.com:
http://www.w3.org/TR/file-writer-api/
On Tue, Jun 1, 2010 at 8:18 AM, Cristiano Sumariva
sumar...@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
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 (イアンフェッティ) ife...@google.comwrote:
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 jo...@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 (イアンフェッティ) ife...@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 jo...@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 (イアンフェッティ) ife...@google.com:
http://www.w3.org/TR/file-writer-api/
On Tue, Jun 1, 2010 at 8:18 AM, Cristiano Sumariva
sumar...@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
Re: HTML5 File
Makes sense to me. (Though I'm still not convinced of its usefulness).
/ Jonas
2010/6/2 Ian Fette (イアンフェッティ) ife...@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 (イアンフェッティ) ife...@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 jo...@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 (イアンフェッティ) ife...@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 jo...@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 (イアンフェッティ) ife...@google.com:
http://www.w3.org/TR/file-writer-api/
On Tue, Jun 1, 2010 at 8:18 AM, Cristiano Sumariva
sumar...@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
