Re: FYI: review of draft-abarth-mime-sniff-03
Adam Barth wrote: Thanks Larry. I'm not subscribed to apps-discuss, so I might not see discussion that takes place there. I'm not sure what the best venue for discussing the draft might be. I suspect that public-html, whatwg, or ietf-http-wg might have the most knowledgeable folks. apps-discuss is the mailing list for the IETF Apps Area, which HTTPbis is part of. Thus I'd really recommend to subscribe (it has a low traffic volume currently). That being said: that confusion can be avoided by noting in the Internet Draft where discussion should happen (optimally, on a mailing list that operates under the IETF IPR rules). Best regards, Julian
Re: [WARP] Extending access to local network resources
On 21 Jan 2010, at 07:18, Arve Bersvendsen wrote: On Thu, 14 Jan 2010 19:04:18 +0100, Stephen Jolly stephen.jo...@rd.bbc.co.uk wrote: Anyway, the specific proposal I would like to make is for another special value of the origin attribute of the access element in the widget configuration document called link-local or similar, an associated special value in the access-request list and an associated processing rule that says that when the link-local value is specified, the user agent should grant access to network resources on the same subnet(s) as the user agent. Just so we are on the same page here, by link-local, you mean exactly what (for IPv4) is defined in RFC 3927, which roughly translates to «Two devices connected directly, without involvment of DHCP» - a.k.a. 169.254.0.0/16? RFC 3927 defines a set of IPv4 addesses that are guaranteed to be either unreachable or assigned to other hosts on the local link. Such hosts may have other addresses though, so I'm defining link-local to *any* address on the local subnet(s). I believe that a user agent can determine this straightforwardly (by resolving the hostname in the requested resource's URL and comparing the routing prefix of the resulting IP address to the routing prefixes of the IP addresses of the host on which the user agent is running, be they IPv4 or IPv6 addresses). Clearly the fact that a host can be connected to multiple networks, consecutively or simultaneously, needs to be taken into account when the policy and user interface for granting network access are implemented, as does the fact that some local networks can contain a large number of untrusted third parties: public WiFi hotspots or mobile data networks, for example. 4. Clearly the local network and the local link are not necessarily the same thing. I'm proposing a solution targeting the latter because (a) it actually has a useful definition and (b) I believe it to be sufficient for the use cases I care about. Provided my understanding of link-local is in line with yours, I would prefer a mechanism for accessing the local network. I look forward to your comments and criticisms - in particular I would like to understand the holes that Arve says are opened by making a distinction between local and remote IP addresses. To moderate my statement a bit - it's more a concern than a risk, when you at all allow access to local network, and you have relaxed cross-domain security, a maliciously crafted widget can potentially attack local networking equipment such as routers. (This risk also exists on the web, but is generally less practical, given that an attacker would be shooting blind due to the same-origin-policy) I agree that link-local security would not protect local network resources from maliciously crafted widgets, but I think that's unavoidable. In this particular respect defining a link-local set of origins offers no additional security over simply using access origin=*/, I agree. However, there are other respects in which additional security is provided (eg the user gains some control over the origins with which potentially private information can be shared), and there are other advantages (eg the user can be moderately confident that a video streaming application is only going to stream from the local network, rather than an expensive connection between the local network and the Internet). The other problem is one of the definition of local network not being entirely clear - the archetypal definition is the IPv4 one with four reserved IP ranges. That definition breaks for IPv6, and it breaks for networks not using NAT. In order to have a useful definition, the network would have to provide information about the locality of any given host a widget tries to access. I believe that the Unique Local Addresses defined by RFC 4193 are the IPv6 equivalent to the reserved private network ranges in IPv4. It might therefore be possible to define a set of non-globally-routable addresses for IPv4 and IPv6 similar to your definition of IPv4 private networks for Opera widgets (http://dev.opera.com/articles/view/opera-widgets-specification-fourth-ed/#private_network), but I think that a link-local restriction is a better match to my use cases. S
Re: [WARP] Extending access to local network resources
On Thu, 21 Jan 2010 12:45:46 +0100, Stephen Jolly stephen.jo...@rd.bbc.co.uk wrote: but I think that a link-local restriction is a better match to my use cases. I'm wondering if you are able to share a few example use cases, to aid understanding of what you want to achieve. -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
[widgets] Draft Minutes for 21 January 2010 voice conference
The draft minutes from the 21 January Widgets voice conference are available at the following and copied below: http://www.w3.org/2010/01/21-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before 4 February (the next Widgets voice conference); otherwise these minutes will be considered Approved. There will be no call on 28 January. -Regards, Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Widgets Voice Conference 21 Jan 2010 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0217.html See also: [3]IRC log [3] http://www.w3.org/2010/01/21-wam-irc Attendees Present Art_Barstow, Marcin_Hanclik, Steve_Jolly, Josh_Soref, Arve, StevenP Regrets Frederick_Hirsch, Marcos_Caceres, Robin_Berjon Chair Art Scribe Art Contents * [4]Topics 1. [5]Review and tweak agenda 2. [6]Announcements 3. [7]WARP spec: LC comments 4. [8]WARP spec: extending access to local network resources 5. [9]URI Scheme spec: LC comments 6. [10]View Modes Media Features spec 7. [11]AOB * [12]Summary of Action Items _ scribe ScribeNick: ArtB scribe Scribe: Art Date: 21 January 2010 marcin ups :) timeless_mbp Zakim: who is on? Review and tweak agenda AB: the agenda was submitted on January 20 ( [13]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/02 17.html ). Any change requests? ... without Robin here, we will need to make some modifications [13] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0217.html Announcements AB: does anyone have any short announcements? The only one I have is that we will not have a call on January 27. WARP spec: LC comments AB: the WARP LC ( [14]http://www.w3.org/TR/2009/WD-widgets-access-20091208/ ) comment period ended 13 January ( [15]http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-a ccess-20091208/ ). I believe we only received 2 comments, from Marcos and Dom. ... Marcos (Dec 21, [16]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/14 72.html ) and Dom (Dec 10, [17]http://www.w3.org/mid/1260460310.3355.2561.ca...@localhost ). ... we can't proceed to CR until we have done the necessary round-tripping with the Commentors [14] http://www.w3.org/TR/2009/WD-widgets-access-20091208/ [15] http://www.w3.org/2006/02/lc-comments-tracker/42538/WD- widgets-access-20091208/ [16] http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/1472.html [17] http://www.w3.org/mid/1260460310.3355.2561.ca...@localhost scribe ACTION: Robin process the LC comments for the WARP LC [recorded in [18]http://www.w3.org/2010/01/21-wam-minutes.html#action01] trackbot Created ACTION-478 - Process the LC comments for the WARP LC [on Robin Berjon - due 2010-01-28]. AB: everyone else in the WG is also encouraged to respond to the LC comments ... anything else on WARP LC? Steven-cwi Apologies for lateness scribe ACTION: barstow make sure all WG members know about the PAG's mail list [recorded in [19]http://www.w3.org/2010/01/21-wam-minutes.html#action02] trackbot Created ACTION-479 - Make sure all WG members know about the PAG's mail list [on Arthur Barstow - due 2010-01-28]. WARP spec: extending access to local network resources AB: on January 14 StephenJ (SJ) started a thread ( [20]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/01 73.html ) re extending the access element to support local network resources. ... Arve and Stephen continued that thread today. What's the status (I haven't yet caught up on today's e-mails)? [20] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0173.html SJ: I sent my proposal ... it is a starting point ... want to consider the local net ... want developers to be able to specify them as accessible ... Arve asked some questions ... I think it makes sense to create some UCs and I'll do that ... if people have other comments, that's good too Arve: for our impl at Opera, developers have been not understood very well the diff between local and non-local ... and have just given permission to everything because of the confusion ... so that is something to consider SJ: needs to be at least one good UX to accept or reject local access ... could be a number of networks available, especially in a mobile network (wifi, operator net, etc.) ... there is lots of more data that may be available Arve: I'm not sure how much we need to standardize SJ: how much info is needed for these UCs? AB:
Re: [selectors-api] comments on Selectors API Level 2
On Wednesday 20 January 2010, Andrew Fedoniouk wrote: Daniel Glazman wrote: I would recommend dropping the pseudo-class :scope and make a simpler model where a fictional :scope pseudo-class and a descendant combinator are prepended to all selectors passed as the argument of the corresponding APIs. There are cases where you will need to match only immediate children using such queryScopedSelector() function. Possible solutions: element.$( .child); element.$(:root .child); :root here is the element itself - root of the lookup. BTW: the name of the function queryScopedSelectorAll() has at least one technical and one grammatical error. Can we rename it somehow? If I read the WD correctly, not only ':scope' is redundant, but queryScopedSelector() and queryScopedSelectorAll() are, too. So I'd suggest: 1) Drop the keyword ':scope'. - It's redundant. The spec says that everywhere you are allowed to use it, you can also omit it and it will be implied. So why not omit it? - It's confusing. You are not allowed to use it everywhere, so it is an opportunity to make mistakes. - It makes the syntax that querySelector() accepts almost the same but not quite as the selectors syntax that CSS allows. Better to either have a completely different syntax or one that is exactly the same, otherwise you just invite errors. 2) Drop queryScopedSelector() and queryScopedSelectorAll(). It is trivially easy to replace a call to queryScopedSelector() by a call to querySelector(). All you have to do is replace e.queryScopedSelector(x) by e.ownerDocument.querySelector(x) where e is an Element. And for documents d the functions are even exactly the same: d.queryScopedSelector(x) == d.querySelector(x) for all documents d and selectors x. - Smaller API means less to implement, - less to test, - less to learn for users. - less variation in programs, - thus easier to understand other people's code. Somebody somewhere else was wondering about the selector ':root + *'. I would say it's a valid selector that just happens to never match anything, because a tree by definition has only one root. The same holds for selectors like '#foo #foo' (valid, but guaranteed to return nothing, because IDs are by definition unique), '*:first-child:even' (the first child is obviously odd, not even), and ':root:first-child' (the root is not a child of anything). Here are some examples of relations that always hold. (Assume e is an element != NULL.) e.querySelector(*) == e.querySelector(:root) e.querySelector(*) == e e.querySelector(:root + *) == NULL e.querySelector(:root:first-child) == NULL e.querySelector(* *) == e.querySelector(:root :first-child) e.querySelector(:odd) == e.querySelector(:root :first-child) Bert -- Bert Bos( W 3 C ) http://www.w3.org/ http://www.w3.org/people/bos W3C/ERCIM b...@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 92 38 76 9206902 Sophia Antipolis Cedex, France
Re: [selectors-api] comments on Selectors API Level 2
On 1/21/10 11:11 AM, Bert Bos wrote: Here are some examples of relations that always hold. (Assume e is an element != NULL.) e.querySelector(*) == e.querySelector(:root) Not unless we've recently redefined :root. Can you point me to the place where that happened? e.querySelector(*) == e Nope. querySelector on an element can only return descendants of the element. In fact, e.querySelector(*) will return the element's first element child, if any. e.querySelector(:root + *) == NULL e.querySelector(:root:first-child) == NULL Agreed, because as currently defined :root will not match anything in the subtree rooted at |e|, ever. e.querySelector(* *) == e.querySelector(:root :first-child) e.querySelector(:odd) == e.querySelector(:root :first-child) Again, not as :root is currently defined. -Boris
Re: [selectors-api] comments on Selectors API Level 2
On Thu, Jan 21, 2010 at 10:11 AM, Bert Bos b...@w3.org wrote: 2) Drop queryScopedSelector() and queryScopedSelectorAll(). It is trivially easy to replace a call to queryScopedSelector() by a call to querySelector(). All you have to do is replace e.queryScopedSelector(x) by e.ownerDocument.querySelector(x) That's completely incorrect. A querySelector call on the document will return all elements that match the selector. A queryScopedSelector call on an element will only return elements that match the selector in the target element's subtree. where e is an Element. And for documents d the functions are even exactly the same: d.queryScopedSelector(x) == d.querySelector(x) for all documents d and selectors x. That doesn't solve the problem, it just says We don't need to solve this problem.. A scoped call on the document root is indeed the same as a non-scoped selector, but that doesn't tell us anything about the actual scoped behavior. It's a degenerate case. Somebody somewhere else was wondering about the selector ':root + *'. I would say it's a valid selector that just happens to never match anything, because a tree by definition has only one root. The same holds for selectors like '#foo #foo' (valid, but guaranteed to return nothing, because IDs are by definition unique), '*:first-child:even' (the first child is obviously odd, not even), and ':root:first-child' (the root is not a child of anything). In a scoped selector, :scope + * *should* return something, if the scoping element has a sibling. It's the behavior of jQuery's find() method (try elem.find(+ *)), and it's what authors are used to. The entire *point* of scoped selectors was to fix the disconnect between querySelector and jQuery, basically. Adding yet another selector function that doesn't act like what current widely-adopted libraries need or what authors expect doesn't help anyone. I don't like the requirement of :scope either, but Lachy took Anne's dislike of starting the string with a bare combinator to be the WG's position as a whole. I think matching jQuery here is *very* important both for author expectations and for practical benefit, and so having e.queryScopedSelectorAll(+ *) do the exact same thing as $(e).find(+ *) is essential. ~TJ
Re: FYI: review of draft-abarth-mime-sniff-03
On Thu, Jan 21, 2010 at 12:52 AM, Julian Reschke julian.resc...@gmx.de wrote: That being said: that confusion can be avoided by noting in the Internet Draft where discussion should happen (optimally, on a mailing list that operates under the IETF IPR rules). Larry suggested that as well. I'll add that when I next update the draft. Adam
Re: [selectors-api] comments on Selectors API Level 2
On Thursday 21 January 2010, Boris Zbarsky wrote:
On 1/21/10 11:11 AM, Bert Bos wrote:
Here are some examples of relations that always hold. (Assume e is
an element != NULL.)
e.querySelector(*) == e.querySelector(:root)
Not unless we've recently redefined :root. Can you point me to the
place where that happened?
e.querySelector(*) == e
Nope. querySelector on an element can only return descendants of the
element. In fact, e.querySelector(*) will return the element's
first element child, if any.
That's surprising... What is the reason to not apply the selector to the
whole tree?
So you're saying that
e.querySelector(:first-child)
gives the first child of e (if any), because in that case e counts as a
parent; but
e.querySelector(* :first-child)
does not, because in this case e *doesn't* count as the parent? And yet
in CSS these two selectors mean the same thing.
It seems rather confusing and unnecessary. It means, e.g., that
D.querySelectorAll(*) doesn't actually return all elements of
document D. (It omits the root.) And that the ':root' selector is
useless in these functions, because any selector with ':root' in it
always returns NULL.
And it is unnecessary, because if you want to exclude e itself from a
query, it's as simple as adding * in front of the selector.
I assumed that, given a document D and a selector S, S in a CSS style
sheet matches exactly the same elements as would be returned by
D.querySelectorAll(S).
E.g., I would think that the following is a nice and short way to check
if a given element e is of type P and has a class abc:
if (e.querySelector(P.abc) == e) {...}
or, equivalently:
if (e.querySelector(P.abc:root) != NULL) {...}
And the one-liner to get all grandchildren of e would be this:
e.querySelectorAll(:root * *)
e.querySelector(:root + *) == NULL
e.querySelector(:root:first-child) == NULL
Agreed, because as currently defined :root will not match anything in
the subtree rooted at |e|, ever.
e.querySelector(* *) == e.querySelector(:root
:first-child)
e.querySelector(:odd) == e.querySelector(:root
:first-child)
Again, not as :root is currently defined.
Bert
--
Bert Bos( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos W3C/ERCIM
b...@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 9206902 Sophia Antipolis Cedex, France
Re: [selectors-api] comments on Selectors API Level 2
On 1/21/10 1:01 PM, Bert Bos wrote:
e.querySelector(*) == e
Nope. querySelector on an element can only return descendants of the
element. In fact, e.querySelector(*) will return the element's
first element child, if any.
That's surprising... What is the reason to not apply the selector to the
whole tree?
I didn't say that the selector is not applied to the whole tree. I said
that only nodes that are descendants of e and match the selector can
be returned by the API.
So you're saying that
e.querySelector(:first-child)
gives the first child of e (if any)
Yes.
e.querySelector(* :first-child)
Does the same thing as e.querySelector(:first-child).
It seems rather confusing and unnecessary. It means, e.g., that
D.querySelectorAll(*) doesn't actually return all elements of
document D. (It omits the root.)
Uh... no. It does in fact return the root.
Again, given a DOM node N the call N.querySelector(someSelector) returns
all elements that:
1) Are descendants of N
2) Match the selector someSelector
Both conditions must be satisfied. If N is a Document, then the root
element of course satisfies condition 1.
And it is unnecessary, because if you want to exclude e itself from a
query, it's as simple as adding * in front of the selector.
As it happens, no. It's not. Unless I'm completely misunderstanding
what you mean here, of course.
I assumed that, given a document D and a selector S, S in a CSS style
sheet matches exactly the same elements as would be returned by
D.querySelectorAll(S).
That's correct.
E.g., I would think that the following is a nice and short way to check
if a given element e is of type P and has a class abc:
if (e.querySelector(P.abc) == e) {...}
You've suddenly switched from calling querySelector on a document to
calling it on an element So not sure how this is an e.g..
But in any case, the above code will always test false. On the other
hand there is a proposal for a matchesSelector() function on elements
which will return a boolean which does exactly what you want here.
Gecko and Webkit have experimental implementations.
And the one-liner to get all grandchildren of e would be this:
e.querySelectorAll(:root * *)
Again, this requires a change in the CSS Selectors definition of :root.
-Boris
Re: File API: Blob and underlying file changes.
Treating blobs as snapshots sounds like a reasonable approach and it will make the life of the chunked upload and other scenarios easier. Now the problem is: how do we get the blob (snapshot) out of the file? 1) We can still keep the current relationship between File and Blob. When we slice a file by calling File.slice, a new blob that captures the current file size and modification time is returned. The following Blob operations, like slice, will simply inherit the cached size and modification time. When we access the underlying file data in XHR.send() or FileReader, the modification time will be verified and an exception could be thrown. 2) We can remove the inheritance of Blob from File and introduce File.getAsBlob() as dimich suggested. This seems to be more elegant. However, it requires changing the File API spec a lot. On Wed, Jan 20, 2010 at 3:44 PM, Eric Uhrhane er...@google.com wrote: On Wed, Jan 20, 2010 at 3:23 PM, Dmitry Titov dim...@chromium.org wrote: On Wed, Jan 20, 2010 at 2:30 PM, Eric Uhrhane er...@google.com wrote: I think it could. Here's a third option: Make all blobs, file-based or not, just as async as the blobs in option 2. They never do sync IO, but could potentially fail future read operations if their metadata is out of date [e.g. reading beyond EOF]. However, expose the modification time on File via an async method and allow the user to pass it in to a read call to enforce fail if changed since this time. This keeps all file accesses async, but still allows for chunked uploads without mixing files accidentally. If we allow users to refresh the modification time asynchronously, it also allows for adding a file to a form, changing the file on disk, and then uploading the new file. The user would look up the mod time when starting the upload, rather than when the file's selected. It would be great to avoid sync file I/O on calls like Blob.size. They would simply return cached value. Actual mismatch would be detected during actual read operation. However then I'm not sure how to keep File derived from Blob, since: 1) Currently, in FF and WebKit File.fileSize is a sync I/O that returns current file size. The current spec says File is derived from Blob and Blob has Blob.size property that is likely going to co-exist with File.fileSize for a while, for compat reasons. It's weird for file.size and file.fileSize to return different things. True, but we'd probably want to deprecate file.fileSize anyway and then get rid of it, since it's synchronous. 2) Currently, xhr.send(file) does not fail and sends the version of the file that exists somewhere around xhr.send(file) call was issued. Since File is also a Blob, xhr.send(blob) would behave the same which means if we want to preserve this behavior the Blob can not fail async read operation if file has changed. There is a contradiction here. One way to resolve it would be to break File is Blob and to be able to capture the File as Blob by having file.getAsBlob(). The latter would make a snapshot of the state of the file, to be able to fail subsequent async read operations if the file has been changed. I've asked a few people around in a non-scientific poll and it seems developers expect Blob to be a 'snapshot', reflecting the state of the file (or Canvas if we get Canvas.getBlob(...)) at the moment of Blob creation. Since it's obviously bad to actually copy data, it seems acceptable to capture enough information (like mod time) so the read operations later can fail if underlying storage has been changed. It feels really strange if reading the Blob can yield some data from one version of a file (or Canvas) mixed with some data from newer version, without any indication that this is happening. All that means there is an option 3: 3. Treat all Blobs as 'snapshots' that refer to the range of underlying data at the moment of creation of the Blob. Blobs produced further by Blob.slice() operation inherit the captured state w/o actually verifying it against 'live' underlying objects like files. All Blobs can be 'read' (or 'sent') via operations that can fail if the underlying content has changed. Optionally, expose snapshotTime property and perhaps read if not changed since parameter to read operations. Do not derive File from Blob, rather have File.getAsBlob() that produces a Blob which is a snapshot of the file at the moment of call. The advantage here is that it removes need for sync operations from Blob and provides mechanism to ensure the changing underlying storage is detectable. The disadvantage is a bit more complexity and bigger change to File spec. That sounds good to me. If we're treating blobs as snapshots, I retract my suggestion of the read-if-not-changed-since parameter. All reads after the data has changed should fail. If you want to do a chunked upload, don't snapshot your
Re: File API: Blob and underlying file changes.
One thing to remember here is that if we require snapshotting, that will mean paying potentially very high costs every time the snapshotting operation is used. Potetially copying hundreds of megabytes of data (think video). But if we don't require snapshotting, things will only break if the user takes the action to modify a file after giving the page access to it. Also, in general snapshotting is something that UAs can experiment with without requiring changes to the spec. Even though File.slice is a synchronous function, the UA can implement snapshotting without using synchronous IO. The UA could simply do a asynchronous file copy in the background. If any read operations are performed on the slice those could simply be stalled until the copy is finished since reads are always asynchronous. / Jonas On Thu, Jan 21, 2010 at 11:22 AM, Eric Uhrhane er...@google.com wrote: On Thu, Jan 21, 2010 at 11:15 AM, Jian Li jia...@chromium.org wrote: Treating blobs as snapshots sounds like a reasonable approach and it will make the life of the chunked upload and other scenarios easier. Now the problem is: how do we get the blob (snapshot) out of the file? 1) We can still keep the current relationship between File and Blob. When we slice a file by calling File.slice, a new blob that captures the current file size and modification time is returned. The following Blob operations, like slice, will simply inherit the cached size and modification time. When we access the underlying file data in XHR.send() or FileReader, the modification time will be verified and an exception could be thrown. This would require File.slice to do synchronous file IO, whereas Blob.slice doesn't do that. 2) We can remove the inheritance of Blob from File and introduce File.getAsBlob() as dimich suggested. This seems to be more elegant. However, it requires changing the File API spec a lot. On Wed, Jan 20, 2010 at 3:44 PM, Eric Uhrhane er...@google.com wrote: On Wed, Jan 20, 2010 at 3:23 PM, Dmitry Titov dim...@chromium.org wrote: On Wed, Jan 20, 2010 at 2:30 PM, Eric Uhrhane er...@google.com wrote: I think it could. Here's a third option: Make all blobs, file-based or not, just as async as the blobs in option 2. They never do sync IO, but could potentially fail future read operations if their metadata is out of date [e.g. reading beyond EOF]. However, expose the modification time on File via an async method and allow the user to pass it in to a read call to enforce fail if changed since this time. This keeps all file accesses async, but still allows for chunked uploads without mixing files accidentally. If we allow users to refresh the modification time asynchronously, it also allows for adding a file to a form, changing the file on disk, and then uploading the new file. The user would look up the mod time when starting the upload, rather than when the file's selected. It would be great to avoid sync file I/O on calls like Blob.size. They would simply return cached value. Actual mismatch would be detected during actual read operation. However then I'm not sure how to keep File derived from Blob, since: 1) Currently, in FF and WebKit File.fileSize is a sync I/O that returns current file size. The current spec says File is derived from Blob and Blob has Blob.size property that is likely going to co-exist with File.fileSize for a while, for compat reasons. It's weird for file.size and file.fileSize to return different things. True, but we'd probably want to deprecate file.fileSize anyway and then get rid of it, since it's synchronous. 2) Currently, xhr.send(file) does not fail and sends the version of the file that exists somewhere around xhr.send(file) call was issued. Since File is also a Blob, xhr.send(blob) would behave the same which means if we want to preserve this behavior the Blob can not fail async read operation if file has changed. There is a contradiction here. One way to resolve it would be to break File is Blob and to be able to capture the File as Blob by having file.getAsBlob(). The latter would make a snapshot of the state of the file, to be able to fail subsequent async read operations if the file has been changed. I've asked a few people around in a non-scientific poll and it seems developers expect Blob to be a 'snapshot', reflecting the state of the file (or Canvas if we get Canvas.getBlob(...)) at the moment of Blob creation. Since it's obviously bad to actually copy data, it seems acceptable to capture enough information (like mod time) so the read operations later can fail if underlying storage has been changed. It feels really strange if reading the Blob can yield some data from one version of a file (or Canvas) mixed with some data from newer version, without any indication that this is happening. All that means there is an option 3: 3. Treat all Blobs as 'snapshots'
Re: File API: Blob and underlying file changes.
On Thu, Jan 21, 2010 at 12:49 PM, Jonas Sicking jo...@sicking.cc wrote: One thing to remember here is that if we require snapshotting, that will mean paying potentially very high costs every time the snapshotting operation is used. Potetially copying hundreds of megabytes of data (think video). I was thinking of different semantics. If the underlying bits change sometime after a 'snapshot' is taken, the 'snapshot' becomes invalid and you cannot access the underying bits. If an application wants guaranteed access to the 'snapshot', it would have to explicitly save a copy somewhere (sandboxed file system / coin a new transient 'Blob' via a new blob.copy() method) and refer to the copy. So no costly copies are made w/o explicit direction to do so from the app. But if we don't require snapshotting, things will only break if the user takes the action to modify a file after giving the page access to it. Also, in general snapshotting is something that UAs can experiment with without requiring changes to the spec. Even though File.slice is a synchronous function, the UA can implement snapshotting without using synchronous IO. The UA could simply do a asynchronous file copy in the background. If any read operations are performed on the slice those could simply be stalled until the copy is finished since reads are always asynchronous. / Jonas On Thu, Jan 21, 2010 at 11:22 AM, Eric Uhrhane er...@google.com wrote: On Thu, Jan 21, 2010 at 11:15 AM, Jian Li jia...@chromium.org wrote: Treating blobs as snapshots sounds like a reasonable approach and it will make the life of the chunked upload and other scenarios easier. Now the problem is: how do we get the blob (snapshot) out of the file? 1) We can still keep the current relationship between File and Blob. When we slice a file by calling File.slice, a new blob that captures the current file size and modification time is returned. The following Blob operations, like slice, will simply inherit the cached size and modification time. When we access the underlying file data in XHR.send() or FileReader, the modification time will be verified and an exception could be thrown. This would require File.slice to do synchronous file IO, whereas Blob.slice doesn't do that. 2) We can remove the inheritance of Blob from File and introduce File.getAsBlob() as dimich suggested. This seems to be more elegant. However, it requires changing the File API spec a lot. On Wed, Jan 20, 2010 at 3:44 PM, Eric Uhrhane er...@google.com wrote: On Wed, Jan 20, 2010 at 3:23 PM, Dmitry Titov dim...@chromium.org wrote: On Wed, Jan 20, 2010 at 2:30 PM, Eric Uhrhane er...@google.com wrote: I think it could. Here's a third option: Make all blobs, file-based or not, just as async as the blobs in option 2. They never do sync IO, but could potentially fail future read operations if their metadata is out of date [e.g. reading beyond EOF]. However, expose the modification time on File via an async method and allow the user to pass it in to a read call to enforce fail if changed since this time. This keeps all file accesses async, but still allows for chunked uploads without mixing files accidentally. If we allow users to refresh the modification time asynchronously, it also allows for adding a file to a form, changing the file on disk, and then uploading the new file. The user would look up the mod time when starting the upload, rather than when the file's selected. It would be great to avoid sync file I/O on calls like Blob.size. They would simply return cached value. Actual mismatch would be detected during actual read operation. However then I'm not sure how to keep File derived from Blob, since: 1) Currently, in FF and WebKit File.fileSize is a sync I/O that returns current file size. The current spec says File is derived from Blob and Blob has Blob.size property that is likely going to co-exist with File.fileSize for a while, for compat reasons. It's weird for file.size and file.fileSize to return different things. True, but we'd probably want to deprecate file.fileSize anyway and then get rid of it, since it's synchronous. 2) Currently, xhr.send(file) does not fail and sends the version of the file that exists somewhere around xhr.send(file) call was issued. Since File is also a Blob, xhr.send(blob) would behave the same which means if we want to preserve this behavior the Blob can not fail async read operation if file has changed. There is a contradiction here. One way to resolve it would be to break File is Blob and to be able to capture the File as Blob by having file.getAsBlob(). The latter would make a snapshot of the state of the file, to be able to fail subsequent async read operations if the file has been changed. I've asked a few people around in a non-scientific
Re: File API: Blob and underlying file changes.
I think the 'snapshotting' discussed above does not imply the actual copy of data, sync or async. The proposal seems to be to 'snapshot' enough information (in case of file on a disk - the modification time is enogh) so that later read operations can fail reliably if the Blob is out of sync with underlying storage. Making copies of large video files will probably never be a feasible option, for size/time issues and for potentially quite complicated lifetime of such copies... We might provide a separate API for file manipulation that can be used to make temporary copies of files in cases where it is a good idea, and that could be used in conjunction with Blob API perhaps, but it seems to be a separate functionality. It is also interesting to think of Blobs backed by some other objects, Canvas for example. Perhaps 'snapshotting' is not an ideal name, but I think discussion above means it as capture the state of the underlying object so the data can be read in the future but w/o a guarantee that the read operation will actually succeed - since there can not be a guarantee that underlying object is still there. On Thu, Jan 21, 2010 at 12:49 PM, Jonas Sicking jo...@sicking.cc wrote: One thing to remember here is that if we require snapshotting, that will mean paying potentially very high costs every time the snapshotting operation is used. Potetially copying hundreds of megabytes of data (think video). But if we don't require snapshotting, things will only break if the user takes the action to modify a file after giving the page access to it. Also, in general snapshotting is something that UAs can experiment with without requiring changes to the spec. Even though File.slice is a synchronous function, the UA can implement snapshotting without using synchronous IO. The UA could simply do a asynchronous file copy in the background. If any read operations are performed on the slice those could simply be stalled until the copy is finished since reads are always asynchronous. / Jonas On Thu, Jan 21, 2010 at 11:22 AM, Eric Uhrhane er...@google.com wrote: On Thu, Jan 21, 2010 at 11:15 AM, Jian Li jia...@chromium.org wrote: Treating blobs as snapshots sounds like a reasonable approach and it will make the life of the chunked upload and other scenarios easier. Now the problem is: how do we get the blob (snapshot) out of the file? 1) We can still keep the current relationship between File and Blob. When we slice a file by calling File.slice, a new blob that captures the current file size and modification time is returned. The following Blob operations, like slice, will simply inherit the cached size and modification time. When we access the underlying file data in XHR.send() or FileReader, the modification time will be verified and an exception could be thrown. This would require File.slice to do synchronous file IO, whereas Blob.slice doesn't do that. 2) We can remove the inheritance of Blob from File and introduce File.getAsBlob() as dimich suggested. This seems to be more elegant. However, it requires changing the File API spec a lot. On Wed, Jan 20, 2010 at 3:44 PM, Eric Uhrhane er...@google.com wrote: On Wed, Jan 20, 2010 at 3:23 PM, Dmitry Titov dim...@chromium.org wrote: On Wed, Jan 20, 2010 at 2:30 PM, Eric Uhrhane er...@google.com wrote: I think it could. Here's a third option: Make all blobs, file-based or not, just as async as the blobs in option 2. They never do sync IO, but could potentially fail future read operations if their metadata is out of date [e.g. reading beyond EOF]. However, expose the modification time on File via an async method and allow the user to pass it in to a read call to enforce fail if changed since this time. This keeps all file accesses async, but still allows for chunked uploads without mixing files accidentally. If we allow users to refresh the modification time asynchronously, it also allows for adding a file to a form, changing the file on disk, and then uploading the new file. The user would look up the mod time when starting the upload, rather than when the file's selected. It would be great to avoid sync file I/O on calls like Blob.size. They would simply return cached value. Actual mismatch would be detected during actual read operation. However then I'm not sure how to keep File derived from Blob, since: 1) Currently, in FF and WebKit File.fileSize is a sync I/O that returns current file size. The current spec says File is derived from Blob and Blob has Blob.size property that is likely going to co-exist with File.fileSize for a while, for compat reasons. It's weird for file.size and file.fileSize to return different things. True, but we'd probably want to deprecate file.fileSize anyway and then get rid of it, since it's synchronous. 2) Currently, xhr.send(file) does not fail and sends the
Re: File API: Blob and underlying file changes.
What we mean for snapshotting here is not to copy all the underlying data. Instead, we only intend to capture the least information needed in order to verify if the underlying data have been changed. I agreed with Eric that the first option could cause inconsistent semantics between File.slice and Bloc.slice. But how are we going to address the synchronous call to get the file size for Blob.size if the blob is a file? On Thu, Jan 21, 2010 at 12:49 PM, Jonas Sicking jo...@sicking.cc wrote: One thing to remember here is that if we require snapshotting, that will mean paying potentially very high costs every time the snapshotting operation is used. Potetially copying hundreds of megabytes of data (think video). But if we don't require snapshotting, things will only break if the user takes the action to modify a file after giving the page access to it. Also, in general snapshotting is something that UAs can experiment with without requiring changes to the spec. Even though File.slice is a synchronous function, the UA can implement snapshotting without using synchronous IO. The UA could simply do a asynchronous file copy in the background. If any read operations are performed on the slice those could simply be stalled until the copy is finished since reads are always asynchronous. / Jonas On Thu, Jan 21, 2010 at 11:22 AM, Eric Uhrhane er...@google.com wrote: On Thu, Jan 21, 2010 at 11:15 AM, Jian Li jia...@chromium.org wrote: Treating blobs as snapshots sounds like a reasonable approach and it will make the life of the chunked upload and other scenarios easier. Now the problem is: how do we get the blob (snapshot) out of the file? 1) We can still keep the current relationship between File and Blob. When we slice a file by calling File.slice, a new blob that captures the current file size and modification time is returned. The following Blob operations, like slice, will simply inherit the cached size and modification time. When we access the underlying file data in XHR.send() or FileReader, the modification time will be verified and an exception could be thrown. This would require File.slice to do synchronous file IO, whereas Blob.slice doesn't do that. 2) We can remove the inheritance of Blob from File and introduce File.getAsBlob() as dimich suggested. This seems to be more elegant. However, it requires changing the File API spec a lot. On Wed, Jan 20, 2010 at 3:44 PM, Eric Uhrhane er...@google.com wrote: On Wed, Jan 20, 2010 at 3:23 PM, Dmitry Titov dim...@chromium.org wrote: On Wed, Jan 20, 2010 at 2:30 PM, Eric Uhrhane er...@google.com wrote: I think it could. Here's a third option: Make all blobs, file-based or not, just as async as the blobs in option 2. They never do sync IO, but could potentially fail future read operations if their metadata is out of date [e.g. reading beyond EOF]. However, expose the modification time on File via an async method and allow the user to pass it in to a read call to enforce fail if changed since this time. This keeps all file accesses async, but still allows for chunked uploads without mixing files accidentally. If we allow users to refresh the modification time asynchronously, it also allows for adding a file to a form, changing the file on disk, and then uploading the new file. The user would look up the mod time when starting the upload, rather than when the file's selected. It would be great to avoid sync file I/O on calls like Blob.size. They would simply return cached value. Actual mismatch would be detected during actual read operation. However then I'm not sure how to keep File derived from Blob, since: 1) Currently, in FF and WebKit File.fileSize is a sync I/O that returns current file size. The current spec says File is derived from Blob and Blob has Blob.size property that is likely going to co-exist with File.fileSize for a while, for compat reasons. It's weird for file.size and file.fileSize to return different things. True, but we'd probably want to deprecate file.fileSize anyway and then get rid of it, since it's synchronous. 2) Currently, xhr.send(file) does not fail and sends the version of the file that exists somewhere around xhr.send(file) call was issued. Since File is also a Blob, xhr.send(blob) would behave the same which means if we want to preserve this behavior the Blob can not fail async read operation if file has changed. There is a contradiction here. One way to resolve it would be to break File is Blob and to be able to capture the File as Blob by having file.getAsBlob(). The latter would make a snapshot of the state of the file, to be able to fail subsequent async read operations if the file has been changed. I've asked a few people around in a non-scientific poll and it seems developers expect Blob to be
Re: A Method for Writing Testable Conformance Clauses and its Applications (Was Re: Write up of test assertion extraction methodology)
Hi Scott, On Jan 20, 2010, at 9:51 PM, Scott Wilson scott.bradley.wil...@gmail.com wrote: Hi Marcos, I think this is a really good piece of work - I'll be pointing a few people from other spec orgs at the draft as its addressing a common requirement. Excellent, thanks. (As an implementer I found the approach - especially the implementation reports - really useful and easy to follow in practice.) I'm happy to hear that you found them useful! In the future, I want to make the table sortable (e.g. group by verdict or only show fails, etc.), and allow the ability to remove implementations from table, so it's easier to compare (e.g., A vs B). if you have any further suggestions to make imp reports more usable, please let me know. S On 19 Jan 2010, at 15:49, Marcos Caceres wrote: Hi all, A draft of A Method for Writing Testable Conformance Clauses and its Applications in now available for review online [1]. For those that have not seen it, it basically just documents how we are standardizing the Widget specs and some basic QA processes: http://dev.w3.org/2008/dev-ind-testing/extracting-test-assertions-pub.html Please consider this a working draft, as it likely contains typos, and a couple of half-baked ideas, etc. Comments are, of course, welcomed. It is expected that this document will be published as a working group note at some point in the future. Kind regards, Marcos Marcos Caceres wrote: Dominique Hazael-Massieux wrote: Hi Marcos, Le mardi 05 janvier 2010 à 17:45 +0100, Dominique Hazael-Massi eux a écrit : Le mardi 05 janvier 2010 à 17:44 +0100, Marcos Caceres a écrit : I was literally doing an editorial pass right now. I would appreciate another day or two to finish (and for you and the WG to have a chance to review the changes). If I check-in a draft by Thursday, could we aim to publish next week? Sure, sounds good to me. Thanks for your help on this! Any news on your editing pass :) ? Sorry, I'm still working on it... it's taking a little longer than I first anticipated :( I've rewritten most of it to describe a bit more clearly how the method was applied.
Re: A Method for Writing Testable Conformance Clauses and its Applications (Was Re: Write up of test assertion extraction methodology)
On Jan 20, 2010, at 6:03 AM, Doug Schepers schep...@w3.org wrote: Hi, Marcos- Marcos Caceres wrote (on 1/19/10 10:49 AM): Hi all, A draft of A Method for Writing Testable Conformance Clauses and its Applications in now available for review online [1]. For those that have not seen it, it basically just documents how we are standardizing the Widget specs and some basic QA processes: http://dev.w3.org/2008/dev-ind-testing/extracting-test-assertions-pub.html Please consider this a working draft, as it likely contains typos, and a couple of half-baked ideas, etc. Comments are, of course, welcomed. It is expected that this document will be published as a working group note at some point in the future. This is an interesting doc and case study, with useful best- practices that mirror some of my own experience in creating specs and test suites. I plan on integrating this into specs I edit, where possible. I think you could emphasize algorithms a bit more, which is traditionally a weak point in W3C specs. Can you elaborate a bit here. I'm really interested because I've recieved both positive and negative feedback about algoriths. E.g. Some say it's great to have them as step by step; others says it's overly prescriptive and takes the freedom/fun/art out of implementing. It may or may not be appropriate for this document to discuss document readability more; W3C specs traditionally serve multiple audiences, such as implementers, tutorial/book writers, and content creators (authors), and while there is a move to make specs more implementer-focused and separate out these concerns, this decreases the value of the specs as community artifacts, makes tutorials more likely to be available only much later and to be error-prone, since they are not written by the same group of people who wrote the prose of the spec. Agree completely; you've exposed my political agenda:) I strongly believe specs should be legible and usable by all its community of users. I don't believe implementers should be priveledged and that they have same magical ability to read specs that we mere mortals lack. I believe specs should be written as accesible as possible in their language and structure. I really like the goal and execution of this practice. Some of it reminds me of my experimental Speki [1] project, which was an exploration of a wiki toolbar to mark up specs for easier spec production. One aspect of this was to create special stylesheets for making the conformance criteria more obvious (follow the link, and select the implementers presentation on the sidebar for a demonstration). I applied some of this markup to DOM3 Events, but not consistently enough. This was part of my Project Tinker [2] architecture proposal (which I've neglected for a year or two). I'll be sure to take a look. Overall, I am very supportive of this kind of detailed analysis, and I appreciate the time and care you took to develop and write it up. Thanks! This kind of document stands to make the production and quality of specs much better. My chief suggestion is that, having developed your workflow and tools, you should make them available to other groups; I've been talking to Robin about adding what is relevant to ReSpec. We have not yet reached any agreement, however. I am interested in reusing your tools for DOM3 Events and SVG, specifically the markup and implementation report tools, and with some modification, the test suite markup and tools. Great! SVG has its own tools and processes for some parts of this, but I strongly believe that the benefit increases the more specs use the same toolchain. Agreed. Here are some specific comments, mostly typo corrections or clarification suggestions: I think Dom has now integrated your suggestions/fixes. 1. Common mistakes * For each of the commons mistakes, include corrections for the faulty prose. 2. The method * stable identifier may be a little vague and abstract; if you mean to add an @id, say, give them a stable identifier, (such as) an 'id' attribute value that is consistent between drafts. If you mean something else, describe it. * Typo: (see ) * Typo: learnt - learned 2.1 Relationship to the standardization process * tangible objects: it might be better to use the term deliverables, since that is the wording of the Process Document and charters; at the least, associate the 2 terms... tangible objects (also called the deliverables of the group) .. * Include issue tracking software in the list of tools provided by the W3C, which can be used as part of the test/spec feedback loop. 3. Structural components of a conformance clause * Product might be better stated as a Conformance Category, which includes authoring tools and authors. While tests against authored content are not in the scope for this document, editors need to be aware
