Reminder: Seeking comments on LCWDs of Server-events, Web Storage, Web Workers; deadline 30-June-2010
Hixie - would you please provide a short status and plan for these docs? -Thanks, Art Barstow Original Message Subject: Seeking comments on LCWDs of Server-events, Web Storage, Web Workers; deadline 30-June-2010 Date: Tue, 22 Dec 2009 18:37:20 +0100 From: Arthur Barstow art.bars...@nokia.com To: public-webapps public-webapps@w3.org On December 22 WebApps published the following Last Call Working Drafts (LCWD): 1. Server-Sent Events http://www.w3.org/TR/2009/WD-eventsource-20091222/ 2. Web Storage http://www.w3.org/TR/2009/WD-webstorage-20091222/ 3. Web Workers http://www.w3.org/TR/2009/WD-workers-20091222/ The deadline for comments is 30 June 2010 and the list for comments is: public-webapps@w3.org -Art Barstow
Automatic translation/validation of WebIDL documents
Dear Doug, all, i am participating the W3C Media Annotations Working Group [1] and co- edit the API for Resource 1.0 document [2]. Since we are going to LC soon, we want to initiate implementing the API specified. The main intention is, that we translate the WebIDL specification of the API automatically by the use of a WebIDL parser. Yet, we have identified the esidl parser [3], which is able to perform the transformation of WebIDL descriptions into method stubs (e.g., C++ or Java). We tried to translate our API, but translation errors occurd (e.g., because of array definitions). I found a mailing list entry about a discussion [4] regarding WebIDL and Arrays - maybe the translation error is somehow linked with this problem? My overall question is, if you have any experience with WebIDL parser, or perhaps could point me to a project, which is most up-to-date to the current version of the WebIDL specification? I have also tried to validate our API spec using the validator of [5], but i am not quiet sure if this validator is able to handle the array definitions. Do you know also a validator, to make sure if our spec is correct? Thanks in advance! Best regards, Florian [1] http://www.w3.org/2008/WebVideo/Annotations/ [2] http://www.w3.org/2008/WebVideo/Annotations/drafts/API10/LC/Overview.html (LC version) [3] http://code.google.com/p/es-operating-system/wiki/esidl [4] http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/0092.html [5] http://widl.webvm.net/ _ Dipl. Inf. Florian Stegmaier Chair of Distributed Information Systems University of Passau Innstr. 43 94032 Passau Room 248 ITZ Tel.: +49 851 509 3063 Fax: +49 851 509 3062 steg...@dimis.fim.uni-passau.de https://www.dimis.fim.uni-passau.de/iris/ http://twitter.com/fstegmai _
Re: Reminder: Seeking comments on LCWDs of Server-events, Web Storage, Web Workers; deadline 30-June-2010
On Wed, 2 Jun 2010, Arthur Barstow wrote: Hixie - would you please provide a short status and plan for these docs? 1. Server-Sent Events http://www.w3.org/TR/2009/WD-eventsource-20091222/ 2. Web Storage http://www.w3.org/TR/2009/WD-webstorage-20091222/ 3. Web Workers http://www.w3.org/TR/2009/WD-workers-20091222/ I hope to have CR drafts for the above specifications ready in July, assuming no further feedback is received. If further feedback is received, it may take a bit longer. Subsequently, I expect to receive implementation feedback resulting in changes over the next few years, in conjunction with the creation of thorough test suites for these drafts, culminating in a PR in a decade or so once two bug-free widely-available non-experimental implementations of each draft exist (as determined by the test suites). HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Automatic translation/validation of WebIDL documents
Le mercredi 02 juin 2010 à 13:40 +0200, Florian Stegmaier a écrit : My overall question is, if you have any experience with WebIDL parser, or perhaps could point me to a project, which is most up-to-date to the current version of the WebIDL specification? I have also tried to validate our API spec using the validator of [5], but i am not quiet sure if this validator is able to handle the array definitions. Do you know also a validator, to make sure if our spec is correct? My understanding is that the WebIDL spec still needs to be updated to reflect the addition of arrays (i.e. no change in that regard since [4]). In particular, their lack of formal definitions in the grammar means that WIDLproc [5] doesn't accept them, which also implies that the on-line WebIDL checker marks them as invalid: http://www.w3.org/2009/07/webidl-check Dom [1] http://www.w3.org/2008/WebVideo/Annotations/ [2] http://www.w3.org/2008/WebVideo/Annotations/drafts/API10/LC/Overview.html (LC version) [3] http://code.google.com/p/es-operating-system/wiki/esidl [4] http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/0092.html [5] http://widl.webvm.net/
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
[widgets] Draft agenda for 3 June 2010 voice conf
Below is the draft agenda for the June 3 Widgets Voice Conference (VC). Inputs and discussion before the VC on all of the agenda topics via public-webapps is encouraged (as it can result in a shortened meeting). Please address Open/Raised Issues and Open Actions before the meeting: http://www.w3.org/2008/webapps/track/products/8 Minutes from the last VC: http://www.w3.org/2010/05/27-wam-minutes.html -Regards, Art Barstow Agenda: 1. Review and tweak agenda 2. Announcements 3. Digital Signature spec http://dev.w3.org/2006/waf/widgets-digsig/ a. LC comment period ended June 1 (no comments submitted); proposal to publish Candidate Recommendation 4. Packaging and Configuration spec http://dev.w3.org/2006/waf/widgets/ a. Comments from I18N WG: comment 21: i18n string http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0859.html comment 22: Default content http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0860.html comment 23: i18n string http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0861.html comment 21: Language tag case http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0862.html b. Comments from Addison Phillips: http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0863.html c. Publishing Proposed Recommendation 5. View Modes Media Feature spec a. Comments from Jim Allan http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0858.html 6. AOB a. Continue discussion from May 27 re GZip, streaming and widget packaging: http://www.w3.org/2010/05/27-wam-minutes.html#item06 Logistics: Time: 22:00 Tokyo; 16:00 Helsinki; 15:00 Paris; 14:00 London; 09:00 Boston; 06:00 Seattle Duration: 90 minutes max Zakim Bridge:+1.617.761.6200, +33.4.89.06.34.99 or +44.117.370.6152 PIN: 9231 (WAF1); IRC: channel = #wam; irc://irc.w3.org:6665 ; http://cgi.w3.org/member-bin/irc/irc.cgi Confidentiality of minutes: Public
Re: comments
On 5/28/10 2:15 PM, ext Marcos Caceres wrote: On Fri, May 28, 2010 at 4:52 PM, Robin Berjonro...@berjon.com wrote: Hi Jim, your comments reach us right after the WG decided to take the specification to CR, but thankfully I was a bit slow with the editing so that we could take them into account :) On May 27, 2010, at 22:42 , Jim Allan wrote: View-mode: fullscreen. It is not clear whether fullscreen includes a full set of chrome, or includes no chrome. You mention 'chrome' in the 'windowed' and 'floating' viewmodes. For consistency, chrome presence should be noted in fullscreen. That's correct, I've now clarified this by adding a mention of chrome for both fullscreen and maximized. It should be noted that the User Agent Accessibility Guidelines 2.0 [1] has success criteria that allow the user to override author settings for a variety of viewport view-modes including the inclusion/exclusion of 'chrome.' Yes, and that's fine. The idea here is that the UA would make a best effort at matching the intent in a way that makes sense rather than be ultra strict. For instance, if the app goes fullscreen but keeps a teeny bit of chrome (at user option or not) to make it easier to exit fullscreen, then matching the view-mode: fullscreen media query is quite clearly the right thing to do. Please consider including a statement such as The user agent *must* display the view-modes in a manner that meets the accessibility guidelines of UAAG20. As much as I'd like more UAs to support UAAG I don't think that this requirement is appropriate here. The VM specification defines a technology with a single purpose: if the window in which the content is being rendered is like this, then apply these CSS style rules. It does *not* define how a UA ought to display an actual set of window states, it doesn't in fact even require UAs to support all the view modes. I'd expect that an application running on an iPhone would only support maximized and fullscreen — if it applied different style rules for each, it would still be 100% conformant. FWIW, I agree with Robin here. I also agree with Robin and Marcos. Jim, WAI UA community - please let us know (as soon as possible) whether or not Robin's response and edits adequately address your comments. -Regards, Art Barstow
Re: [IndexedDB] [Bug 9562] New: Opening a database with a different description is underspecified
On Mon, May 24, 2010 at 9:41 PM, Shawn Wilsher sdwi...@mozilla.com wrote: On 4/20/2010 11:46 AM, bugzi...@jessica.w3.org wrote: The spec is unspecified as to what we should do when a database is opened with a different description than it was previously opened. I'd assume we'd want to update the description. Does anybody else have thoughts on what the right behavior should be here? Probably just overrite with the latest version of the description? As such, it might make sense to make it optional.
[Bug 9698] Rename all instances of noOverwrite to overwite
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9698 Jeremy Orlow jor...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jor...@chromium.org Resolution||DUPLICATE --- Comment #1 from Jeremy Orlow jor...@chromium.org 2010-06-02 14:01:23 --- *** This bug has been marked as a duplicate of bug 9769 *** -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [IndexedDB] KeyPaths and missing properties.
On Fri, May 21, 2010 at 12:39 AM, Jonas Sicking jo...@sicking.cc wrote: So you'd have to pass in the javascript expression as a string. This certainly works but is more than a little ugly. It also complicates the implementation a good bit since it now has to include a javascript engine. Not a huge issue given that all browsers has one anyway, but feels a bit iffy. Hm. I'm looking at the spec, and I can't find where (if anywhere) it talks about what's allowed as a key path. I guess I had assumed that it was essentially javascript (or maybe some subset) and that we'd at least need to be parsing it anyway. If we don't adopt this idea because we're worried about depending on javascript, then we should spec out the keyPath syntax pretty precisely to ensure we don't have such a dependency. snip I think the intent of the current syntax is that it's a '.' separated list of property names. But yes, it definitely needs to be precisely defined. I'll create a bug for this and the other items we've already decided on in this thread. I still think it's an interesting idea, though I'm not sold on it. Especially for the first version of the spec. It seems like there would be a lot of edge cases to define here. First of all, how is the value passed in to this expression? Do we say that it's available through some value variable? So that if you want to index on the foo property, you pass in an expression like value.foo? Or do we want the value to be the global object, so that if you wanted to index on the foo property the expression would simply be foo? Since we're already talking about requiring that data being inserted into objectStores with a keyPath (for its primary key or in one of its indexes), setting it as the global object seems reasonable. And it matches what's currently specced for the simple 1 entityStore entry to 1 index entry (per index) case. You also have to specify how the value is returned. I.e. does the expression need to end with 'return X'? Or do we index on the result of the value returned from the last executed expression? Also, I think that if the value is the global object, then I declaring variables inside the expression modifies the value as global variables are set on the global object. Also, what happens if the javascript expression modifies the value? Does the implementation have to clone the value before calling each index expression? In order of how much I like the idea: 1) In an ideal world, we'd spec it to be read only, but I'm not sure if most JS engines have an easy way to do something like that. 2) Another possibility is to make the order in which indexes are processed deterministic. That way, if someone does modify it, it'll at least be consistent. 3) Cloning is another possibility, but it seems like it'd have a performance impact. Maybe optimized implementations could copy-on-write it, though? I think 1 and 3 suffers from the same problem of not being something that JS engines usually need to do, and so likely isn't implemented. In both cases you have to be able to mark an object graph such that you take special action if it's modified. And for 2, do you do the structured clone before or after you run the keyPath expressions? Not until after you've created the structured clone will you know if the value can even be stored. In short, I'd like to see a comprehensive proposal :) Then I could take that to the JS team and ask if it's implementable. Per other threads, it looks like we should make sure IndexedDB does not depend on JavaScript, so please ignore my proposal. On Thu, May 20, 2010 at 4:56 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, May 20, 2010 at 7:55 AM, Andrei Popescu andr...@google.com wrote: Hi, On Thu, May 20, 2010 at 10:47 AM, Jeremy Orlow jor...@chromium.org wrote: On Thu, May 20, 2010 at 1:24 AM, Jonas Sicking jo...@sicking.cc wrote: It seems like there would be a lot of edge cases to define here. First of all, how is the value passed in to this expression? Do we say that it's available through some value variable? So that if you want to index on the foo property, you pass in an expression like value.foo? Or do we want the value to be the global object, so that if you wanted to index on the foo property the expression would simply be foo? Since we're already talking about requiring that data being inserted into objectStores with a keyPath (for its primary key or in one of its indexes), setting it as the global object seems reasonable. And it matches what's currently specced for the simple 1 entityStore entry to 1 index entry (per index) case. Also, what happens if the javascript expression modifies the value? Does the implementation have to clone the value before calling each index expression? In order of how much I like the idea: 1) In an ideal world, we'd spec it to be read
[Bug 9832] New: keyPath is underspecified
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9832 Summary: keyPath is underspecified Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: nikunj.me...@oracle.com ReportedBy: jor...@chromium.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org KeyPaths and their underspecification has come up in several threads, but especially [IndexedDB] KeyPaths and missing properties [1]. We need to have normative text describing how to parse keyPath and how a keyPath maps to properties of a value. We need to decide whether we want to allow explicit index management and whether we want this to be done via ObjectStore's add/modify/addOrModify or whether we want to have methods hanging off of each index to do this. We need to decide what to do if the key corresponding to a keyPath doesn't exist (insert null, insert nothing, or raise error). This list may be incomplete. [1] http://www.mail-archive.com/public-webapps@w3.org/msg08862.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
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: XMLHttpRequest Priority Proposal
Finally cycling back on this.
Based on feedback from Olli and Anne, I have revised the spec.
Changes:
* changed the setPriority() method to be an attribute priority
* made priority be a string rather than a number
* inserted the NORMAL priority as the default XHR priority
Here is the updated doc.
Olli has implemented a patch (for the old spec) already:
https://bugzilla.mozilla.org/show_bug.cgi?id=559092
We'll be working on a Chromium/Webkit one shortly.
Mike
XMLHttpRequest Priority FetchingEvery performant web browser implementation
today implements various heuristics for resource loading prioritization
internally. The notion is simple, that loading some resources, such as
images, are less performance critical than loading other resources, such as
external style sheets. By implementing basic priorities, browsers achieve
substantially better performance loading web pages. Today, however, web
applications have no way of giving hints to the browser about what may be
high or low priority.
Because complex applications heavily rely on resource loading by way of
XmlHttpRequest, we propose a simple, backward compatible, and optional
mechanism whereby application developers can hint to a browser how to load a
XmlHttpRequest.
Proposed API:
interface XMLHttpRequest {
// Set the load priority for this request.
// The priority must be set before calling send().
// Valid priorities are:
// “CRITICAL”, “HIGH”, “NORMAL”, “LOW”, “LOWEST”
attribute string priority;
}
Example Usage:
var client = new XMLHttprequest;
client.priority = “HIGH”;
client.open(’GET’, ‘demo.cgi’);
client.send();
Description:
When a new XMLHttpRequest object is created, it contains a notion of
priority. Browsers which schedule resource fetches may optionally use this
priority to determine in which order resources are fetched.
5 priorities are provided. By keeping the number of different priorities
small, we keep browser and XMLHttpRequest priority implementations simple.
By default, all XMLHttpRequest objects have a priority “NORMAL”.
Applications may alter the priority by calling the setPriority() method on
the XMLHttpRequest object. The priority set on the object at the time the
applicaiton calls the XMLHttpRequest.send() method determines the priority
the browser should use when fetching this resource. Calling setPriority()
after the send() method will have no effect on the priority of the resource
load.
Browsers are not required to support the priority requested by applications,
and may ignore it altogether. However, browsers are encouraged to support
the requested priority order. The following is a description of one
possible prioritization policy:
CRITICAL resources are loaded first. When CRITICAL resources are in
progress, requests for HIGH-LOWEST resources are deferred until all CRITICAL
resources have finished.
HIGH-LOWEST resources are loaded in that order. When no CRITICAL
resources are in progress, HIGH-LOWEST resources will be loaded with HIGH
priority first. The browser does not need to wait until higher priority
resources have finished fetching before it starts a request for a lower
priority resource, although it may chose to do so.
Existing Implementations: Google is currently using resource prioritization
techniques in its Google Maps application, internally to the Google Chrome
browser, and also as a part of the SPDY protocol.
On Sun, Apr 18, 2010 at 10:37 PM, Anne van Kesteren ann...@opera.comwrote:
On Fri, 16 Apr 2010 18:03:08 +0900, Mike Belshe mbel...@google.com
wrote:
On Fri, Apr 16, 2010 at 1:37 AM, Anne van Kesteren ann...@opera.com
wrote:
I didn't actually propose an error condition and I'll note that your
setPriority() proposal didn't handle errors either. E.g. what happens
when I pass 20 as argument?
Fair enough. :-)
What I wanted was an enum, but I don't believe there is a way to do enums,
right?
Not currently, no.
I think easiest would be to just ignore the setting as e.g. lineCap and
lineJoin on the canvas 2D API do. Then errors are gracefully handled and
by
checking what priority is after setting you can see whether the
implementation supports the feature.
I'd take whatever people like most. Personally, I don't like using
strings for enums, but I can live with it.
So you're proposing something like:
var my_priority = HGIH;
xhr.priority = my_priority;
if (xhr.priority != my_priority) {
// we detected an error
}
Yeah. Basically using strings makes it easier to extend the API going
forward as numbers start clashing pretty soon.
--
Anne van Kesteren
http://annevankesteren.nl/
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: XMLHttpRequest Priority Proposal
On Fri, 16 Apr 2010 07:00:56 +0100, Anne van Kesteren ann...@opera.com wrote: On Wed, 14 Apr 2010 01:13:46 +0900, Mike Belshe mbel...@google.com wrote: // Set the load priority for this request. void setPriority(unsigned short priority); Any reason this is not an attribute named priority? Other than that I wonder if we should maybe simply use string values to make it easier to extend this if we ever need to. How is it easier to extend ? Like, define an interval from, say, 1 to 10, 5 is normal, 10 is high then let the UA decide how to deal better with prioritization. Handling strings for such a simple use case is messy, and very different from all the other dom bindings that use integers already (e.g. nodeType, readyState).
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
Re: Updates to File API
Arun: In the latest version of the spec I see that readAsDataURL, alone among the readAs* methods, still takes a File rather than a Blob. Is that just an oversight, or is that an intentional restriction? Eric On Thu, May 13, 2010 at 5:27 AM, Arun Ranganathan a...@mozilla.com wrote: Greetings WebApps WG, I have updated the editor's draft of the File API to reflect changes that have been in discussion. http://dev.w3.org/2006/webapi/FileAPI Notably: 1. Blobs now allow further binary data operations by exposing an ArrayBuffer property that represents the Blob. ArrayBuffers, and affiliated Typed Array views of data, are specified in a working draft as a part of the WebGL work [1]. This work has been proposed to ECMA's TC-39 WG as well. We intend to implement some of this in the Firefox 4 timeframe, and have reason to believe other browsers will as well. I have thus cited the work as a normative reference [1]. Eventually, we ought to consider further read operations given ArrayBuffers, but for now, I believe exposing Blobs in this way is sufficient. 2. url and type properties have been moved to to the underlying Blob interface. Notably, the property is now called 'url' and not 'urn.' Use cases for triggering 'save as' behavior with Content-Disposition have not been addressed[2], although I believe that with FileWriter and BlobBuilder[3] they may be addressed differently. This change reflects lengthy discussion (e.g. start here[4]) 3. The renaming of the property to 'url' also suggests that we should cease to consider an urn:uuid scheme. I solicited implementer feedback about URLs vs. URNs in general. There was a general preference to URLs[5], though this wasn't a strong preference. Moreover, Mozilla's implementation currently uses moz-filedata: . The current draft has an editor's note about the use of HTTP semantics, and origin issues in the context of shared workers. This is work in progress; I have removed the section specifying urn:uuid and hope to have an update with a section covering the filedata: scheme (with filedata:uuid as a suggestion). I welcome discussion about this. I'll point out that we are coining a new scheme, which we originally sought to avoid :-) 4. I have changed event order; loadend now fires after an error event [6]. -- A* [1] https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html [2] http://www.mail-archive.com/public-webapps@w3.org/msg06137.html [3] http://dev.w3.org/2009/dap/file-system/file-writer.html [4] http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0910.html [5] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0462.html [6] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0062.html
Re: Updates to File API
On 6/2/10 3:42 PM, Eric Uhrhane wrote: Arun: In the latest version of the spec I see that readAsDataURL, alone among the readAs* methods, still takes a File rather than a Blob. Is that just an oversight, or is that an intentional restriction? That's intentional; readAsDataURL was cited as useful only in the context of File objects. Do you think it makes sense in the context of random Blob objects? Does it make sense on slice calls on a Blob, for example? -- A*
Re: Updates to File API
On Wed, Jun 2, 2010 at 3:44 PM, Arun Ranganathan a...@mozilla.com wrote: On 6/2/10 3:42 PM, Eric Uhrhane wrote: Arun: In the latest version of the spec I see that readAsDataURL, alone among the readAs* methods, still takes a File rather than a Blob. Is that just an oversight, or is that an intentional restriction? That's intentional; readAsDataURL was cited as useful only in the context of File objects. Do you think it makes sense in the context of random Blob objects? Does it make sense on slice calls on a Blob, for example? Sure, why not? Why would this be limited to File objects? A File is supposed to refer to an actual file on the local hard drive. A Blob is a big bunch of data that you might want to do something with. There's nothing special about a File when it comes to what you're doing with the data. Just as we moved File.url up to Blob, I think File.readAsDataURL belongs there too.
Re: Updates to File API
On 6/2/10 3:48 PM, Eric Uhrhane wrote: Sure, why not? Why would this be limited to File objects? A File is supposed to refer to an actual file on the local hard drive. A Blob is a big bunch of data that you might want to do something with. There's nothing special about a File when it comes to what you're doing with the data. Just as we moved File.url up to Blob, I think File.readAsDataURL belongs there too. Fair enough; I'm amenable to moving it. So specifically, you're okay with a DataURL on a Blob? It might not be anything useful; with a File, you at least have the possibility of a whole unsliced image file. Could you give me a use case where this is really useful for Blob objects? Also, above you probably mean specifying that readAsDataURL (a method on FileReader) works on Blob objects, not File.readAsDataURL ;-) -- A*
Re: Updates to File API
On Wed, Jun 2, 2010 at 3:48 PM, Eric Uhrhane er...@google.com wrote: On Wed, Jun 2, 2010 at 3:44 PM, Arun Ranganathan a...@mozilla.com wrote: On 6/2/10 3:42 PM, Eric Uhrhane wrote: Arun: In the latest version of the spec I see that readAsDataURL, alone among the readAs* methods, still takes a File rather than a Blob. Is that just an oversight, or is that an intentional restriction? That's intentional; readAsDataURL was cited as useful only in the context of File objects. Do you think it makes sense in the context of random Blob objects? Does it make sense on slice calls on a Blob, for example? Sure, why not? Why would this be limited to File objects? A File is supposed to refer to an actual file on the local hard drive. A Blob is a big bunch of data that you might want to do something with. There's nothing special about a File when it comes to what you're doing with the data. Just as we moved File.url up to Blob, I think File.readAsDataURL belongs there too. And we move type from File to Blob.
Re: Updates to File API
On Wed, Jun 2, 2010 at 3:57 PM, Arun Ranganathan a...@mozilla.com wrote: On 6/2/10 3:48 PM, Eric Uhrhane wrote: Sure, why not? Why would this be limited to File objects? A File is supposed to refer to an actual file on the local hard drive. A Blob is a big bunch of data that you might want to do something with. There's nothing special about a File when it comes to what you're doing with the data. Just as we moved File.url up to Blob, I think File.readAsDataURL belongs there too. Fair enough; I'm amenable to moving it. So specifically, you're okay with a DataURL on a Blob? It might not be anything useful; with a File, you at least have the possibility of a whole unsliced image file. Could you give me a use case where this is really useful for Blob objects? One that's come up for Blob.url is a packed file of image thumbnails: you can do one big download, then slice and display the pieces. If you're doing any display by data URLs, that would work there too. To be honest, I think a lot of the data URL use cases are better served by Blob.url anyway, so I'm not sure how many will remain once this spec is fully implemented, but can you think of a data URL use case that really depends on the data coming from a File on disk instead of a Blob? Also, above you probably mean specifying that readAsDataURL (a method on FileReader) works on Blob objects, not File.readAsDataURL ;-) Yeah. Brain-o.
Re: Updates to File API
Hi, Arun, I have one question regarding the scheme for Blob.url. The latest spec says that The proposed URL scheme is filedata:. Mozilla already ships with moz-filedata:. Since the URL is now part of the Blob and it could be used to refer to both file data blob and binary data blob, should we consider making the scheme as blobdata: for better generalization? In addition, we're thinking it will probably be a good practice to encode the security origin in the blob URL scheme, like blobdata: http://example.com/33c6401f-8779-4ea2-9a9b-1b725d6cd50b. This will make doing the security origin check easier when a page tries to access the blob url that is created in another process, under multi-process architecture. Indeed, the URL scheme seems to be more sort of implementation details. Different browser vendors can choose the appropriate scheme, like Mozilla ships with moz-filedata. How do you think? Jian On Thu, May 13, 2010 at 5:27 AM, Arun Ranganathan a...@mozilla.com wrote: Greetings WebApps WG, I have updated the editor's draft of the File API to reflect changes that have been in discussion. http://dev.w3.org/2006/webapi/FileAPI Notably: 1. Blobs now allow further binary data operations by exposing an ArrayBuffer property that represents the Blob. ArrayBuffers, and affiliated Typed Array views of data, are specified in a working draft as a part of the WebGL work [1]. This work has been proposed to ECMA's TC-39 WG as well. We intend to implement some of this in the Firefox 4 timeframe, and have reason to believe other browsers will as well. I have thus cited the work as a normative reference [1]. Eventually, we ought to consider further read operations given ArrayBuffers, but for now, I believe exposing Blobs in this way is sufficient. 2. url and type properties have been moved to to the underlying Blob interface. Notably, the property is now called 'url' and not 'urn.' Use cases for triggering 'save as' behavior with Content-Disposition have not been addressed[2], although I believe that with FileWriter and BlobBuilder[3] they may be addressed differently. This change reflects lengthy discussion (e.g. start here[4]) 3. The renaming of the property to 'url' also suggests that we should cease to consider an urn:uuid scheme. I solicited implementer feedback about URLs vs. URNs in general. There was a general preference to URLs[5], though this wasn't a strong preference. Moreover, Mozilla's implementation currently uses moz-filedata: . The current draft has an editor's note about the use of HTTP semantics, and origin issues in the context of shared workers. This is work in progress; I have removed the section specifying urn:uuid and hope to have an update with a section covering the filedata: scheme (with filedata:uuid as a suggestion). I welcome discussion about this. I'll point out that we are coining a new scheme, which we originally sought to avoid :-) 4. I have changed event order; loadend now fires after an error event [6]. -- A* [1] https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html [2] http://www.mail-archive.com/public-webapps@w3.org/msg06137.html [3] http://dev.w3.org/2009/dap/file-system/file-writer.html [4] http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0910.html [5] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0462.html [6] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0062.html
Re: Updates to File API
On Wed, Jun 2, 2010 at 3:42 PM, Eric Uhrhane er...@google.com wrote: Arun: In the latest version of the spec I see that readAsDataURL, alone among the readAs* methods, still takes a File rather than a Blob. Is that just an oversight, or is that an intentional restriction? Having readAsDataURL take a File made sense when .url and .type lived on File rather than Blob. Now that Blobs have .types I agree that readAsDataURL should be able to read from a Blob. But, as you say, I think .url solves most of the use cases. One usecase I can still think of is a web based HTML editor which allows inserting images. These images could be included inline in the main document using data-urls which allows the document to be saved/sent as a single document, rather than HTML + a pile of images. / Jonas
Re: Updates to File API
On 6/2/10 5:06 PM, Jian Li wrote: Hi, Arun, I have one question regarding the scheme for Blob.url. The latest spec says that The proposed URL scheme is filedata:. Mozilla already ships with moz-filedata:. Since the URL is now part of the Blob and it could be used to refer to both file data blob and binary data blob, should we consider making the scheme as blobdata: for better generalization? In addition, we're thinking it will probably be a good practice to encode the security origin in the blob URL scheme, like blobdata: http://example.com/33c6401f-8779-4ea2-9a9b-1b725d6cd50b. This will make doing the security origin check easier when a page tries to access the blob url that is created in another process, under multi-process architecture. This is a good suggestion. I particularly like the idea of encoding the origin as part of the scheme. Indeed, the URL scheme seems to be more sort of implementation details. Different browser vendors can choose the appropriate scheme, like Mozilla ships with moz-filedata. How do you think? Actually, I'm against leaving it totally up to implementations. Sure, the spec. could simply state how the URL behaves without mentioning format much, but we identified in the past [1] that it was wise to specify things reliably, so that developers didn't rely on arbitrary behavior in one implementation and expect something similar in another. It's precisely that genre of underspecified behavior that got us in trouble before ;-) -- A* [1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0743.html
Re: Updates to File API
I got what you mean. Thanks for clarifying it. Do you plan to add the origin encoding into the spec? How about using more generic scheme name blobdata:? Jian On Wed, Jun 2, 2010 at 5:26 PM, Arun Ranganathan a...@mozilla.com wrote: On 6/2/10 5:06 PM, Jian Li wrote: Hi, Arun, I have one question regarding the scheme for Blob.url. The latest spec says that The proposed URL scheme is filedata:. Mozilla already ships with moz-filedata:. Since the URL is now part of the Blob and it could be used to refer to both file data blob and binary data blob, should we consider making the scheme as blobdata: for better generalization? In addition, we're thinking it will probably be a good practice to encode the security origin in the blob URL scheme, like blobdata: http://example.com/33c6401f-8779-4ea2-9a9b-1b725d6cd50b. This will make doing the security origin check easier when a page tries to access the blob url that is created in another process, under multi-process architecture. This is a good suggestion. I particularly like the idea of encoding the origin as part of the scheme. Indeed, the URL scheme seems to be more sort of implementation details. Different browser vendors can choose the appropriate scheme, like Mozilla ships with moz-filedata. How do you think? Actually, I'm against leaving it totally up to implementations. Sure, the spec. could simply state how the URL behaves without mentioning format much, but we identified in the past [1] that it was wise to specify things reliably, so that developers didn't rely on arbitrary behavior in one implementation and expect something similar in another. It's precisely that genre of underspecified behavior that got us in trouble before ;-) -- A* [1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0743.html
Re: Updates to File API
On Wed, Jun 2, 2010 at 5:26 PM, Arun Ranganathan a...@mozilla.com wrote: On 6/2/10 5:06 PM, Jian Li wrote: Hi, Arun, I have one question regarding the scheme for Blob.url. The latest spec says that The proposed URL scheme is filedata:. Mozilla already ships with moz-filedata:. Since the URL is now part of the Blob and it could be used to refer to both file data blob and binary data blob, should we consider making the scheme as blobdata: for better generalization? In addition, we're thinking it will probably be a good practice to encode the security origin in the blob URL scheme, like blobdata: http://example.com/33c6401f-8779-4ea2-9a9b-1b725d6cd50b. This will make doing the security origin check easier when a page tries to access the blob url that is created in another process, under multi-process architecture. This is a good suggestion. I particularly like the idea of encoding the origin as part of the scheme. Though we want to avoid introducing the concept of nested schemes to the web. While mozilla already uses nested schemes (jar:http://... and view-source:http://...) I know others, in particular Apple, have expressed a dislike for this in the past. And with good reason, it's not easy to implement and has been a source of numerous security bugs. That said, it's certainly possible. / Jonas
