VMMF — new version
Hi all, I just produced an update of VMMF to make it ready for publication: http://dev.w3.org/2006/waf/widgets-vmmf/. Essentially I changed it so that it corresponds to CSS Media Queries. That, plus it being a UI oriented specification, means that there's only one normative assertion and it's a SHOULD. Comments welcome, I think that this baby can ship. -- Robin Berjon - http://berjon.com/
Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
On Wed, Mar 3, 2010 at 8:48 PM, Kris Zyp k...@sitepen.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/3/2010 4:01 AM, Jeremy Orlow wrote:
On Wed, Mar 3, 2010 at 4:49 AM, Kris Zyp k...@sitepen.com
mailto:k...@sitepen.com k...@sitepen.com wrote:
[snip]
The promises would only have a
then method which would take in an
onsuccess and onerror callback. Both are optional. The
onsuccess
function should take in a single parameter which matches the
return
value of the synchronous counterpart. The onerror function
should
take in an IDBDatabaseError. If the callbacks are null,
undefined,
or omitted, they're ignored. If they're anything else, we should
probably either raise an exception immediately or ignore them.
Yes.
Any thoughts on whether we'd raise or ignore improper inputs? I'm
leaning towards raise since it would be deterministic and silently
ignoring seems like a headache from a developer standpoint.
Throwing an error on improper inputs is fine with me.
If there's an error, all onerror
callbacks would be called with the
IDBDatabaseError.
Yes.
Exceptions within callbacks
would be ignored.
With CommonJS promises, the promise returned by the then() call goes
into an error state if a callback throws an exception. For example,
someAsyncOperation.then(successHandler, function(){ throw new
Error(test) })
.then(null, function(error){ console.log(error); });
Would log the thrown error, effectively giving you a way of catching
the error.
Are you suggesting this as a simplification so that IndexedDB impls
doesn't have to worry about recursive creation of promises? If so, I
suppose that seems like a reasonable simplification to me.
Although if
promises are something that could be potentially reused in other
specs, it would be nice to have a quality solution, and I don't
think
this is a big implementation burden, I've implemented the recursive
capabilities in dozen or two lines of JS code. But if burden is too
onerous, I am fine with the simplification.
When you say recursive capabilities are you just talking about how
to handle exceptions, or something more?
In terms of exceptions: I don't think it's an
enormous implementational burden and thus I think it's fine to
ignore that part of the equation. So the question mainly comes down
to whether the added complexity is worth it. Can you think of any
real-world examples of when this capability is useful in promises?
If so, that'd definitely help us understand the pro's and con's.
Maybe I misunderstanding your suggestion. By recursive capability I
meant having then() return a promise (that is fulfilled with the
result of executing the callback), and I thought you were suggesting
that instead, then() would not return a promise. If then() returns a
promise, I think the returned promise should clearly go into an error
state if the callback throws an error. The goal of promises is to
asynchronously model computations, and if a computation throws, it
should result in the associated promise entering error state. The
promise returned by then() exists to represent the result of the
execution of the callback, and so it should resolve to the value
returned by the callback or an error if the callback throws. Silenty
swallowing errors seems highly undesirable.
Now if we are simplifying then() to not return a promise at all, than
I would think callbacks would just behave like any other event
listener in regards to uncaught errors.
You are quite right! I misunderstood how this part of promises worked.
Is there excitement about speccing promises in general? If not, it seems a
little odd to spec such a powerful mechanism into just IndexedDBand it
might be best to spec the simplified version of .then(): .then() will return
undefined, onsuccess/onerror's return values will be swallowed, and any
thrown exceptions will be thrown.
This should make it easy to make IndexedDB support full blown promises
if/whenever they're specced. (It's not clear to me whether UA support for
them would offer enough advantages to warrant it.)
It sounds like you're OK with such an approach, Kris?
What do others think?
J
In terms of speccing, I'm not sure if we can get away with
speccing
one promise interface or whether we'd need to create one for each
type of promise.
Certainly the intent of promises is that there is exists only one
generic promise interface that can be reused everywhere, at
least from
the JS perspective, not sure if the extra type constraints in IDL
demand multiple interfaces to model promise's effectively
parameterized generic type form.
Unfortunately, I
Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
On Thu, Mar 4, 2010 at 2:37 PM, Jeremy Orlow jor...@chromium.org wrote:
On Wed, Mar 3, 2010 at 8:48 PM, Kris Zyp k...@sitepen.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/3/2010 4:01 AM, Jeremy Orlow wrote:
On Wed, Mar 3, 2010 at 4:49 AM, Kris Zyp k...@sitepen.com
mailto:k...@sitepen.com k...@sitepen.com wrote:
[snip]
The promises would only have a
then method which would take in an
onsuccess and onerror callback. Both are optional. The
onsuccess
function should take in a single parameter which matches the
return
value of the synchronous counterpart. The onerror function
should
take in an IDBDatabaseError. If the callbacks are null,
undefined,
or omitted, they're ignored. If they're anything else, we should
probably either raise an exception immediately or ignore them.
Yes.
Any thoughts on whether we'd raise or ignore improper inputs? I'm
leaning towards raise since it would be deterministic and silently
ignoring seems like a headache from a developer standpoint.
Throwing an error on improper inputs is fine with me.
If there's an error, all onerror
callbacks would be called with the
IDBDatabaseError.
Yes.
Exceptions within callbacks
would be ignored.
With CommonJS promises, the promise returned by the then() call goes
into an error state if a callback throws an exception. For example,
someAsyncOperation.then(successHandler, function(){ throw new
Error(test) })
.then(null, function(error){ console.log(error); });
Would log the thrown error, effectively giving you a way of catching
the error.
Are you suggesting this as a simplification so that IndexedDB impls
doesn't have to worry about recursive creation of promises? If so, I
suppose that seems like a reasonable simplification to me.
Although if
promises are something that could be potentially reused in other
specs, it would be nice to have a quality solution, and I don't
think
this is a big implementation burden, I've implemented the recursive
capabilities in dozen or two lines of JS code. But if burden is too
onerous, I am fine with the simplification.
When you say recursive capabilities are you just talking about how
to handle exceptions, or something more?
In terms of exceptions: I don't think it's an
enormous implementational burden and thus I think it's fine to
ignore that part of the equation. So the question mainly comes down
to whether the added complexity is worth it. Can you think of any
real-world examples of when this capability is useful in promises?
If so, that'd definitely help us understand the pro's and con's.
Maybe I misunderstanding your suggestion. By recursive capability I
meant having then() return a promise (that is fulfilled with the
result of executing the callback), and I thought you were suggesting
that instead, then() would not return a promise. If then() returns a
promise, I think the returned promise should clearly go into an error
state if the callback throws an error. The goal of promises is to
asynchronously model computations, and if a computation throws, it
should result in the associated promise entering error state. The
promise returned by then() exists to represent the result of the
execution of the callback, and so it should resolve to the value
returned by the callback or an error if the callback throws. Silenty
swallowing errors seems highly undesirable.
Now if we are simplifying then() to not return a promise at all, than
I would think callbacks would just behave like any other event
listener in regards to uncaught errors.
You are quite right! I misunderstood how this part of promises worked.
Is there excitement about speccing promises in general? If not, it seems a
little odd to spec such a powerful mechanism into just IndexedDBand it
might be best to spec the simplified version of .then(): .then() will return
undefined, onsuccess/onerror's return values will be swallowed, and any
thrown exceptions will be thrown.
Erthrown exceptions will be _swallowed_ (not thrown).
This should make it easy to make IndexedDB support full blown promises
if/whenever they're specced. (It's not clear to me whether UA support for
them would offer enough advantages to warrant it.)
It sounds like you're OK with such an approach, Kris?
What do others think?
J
In terms of speccing, I'm not sure if we can get away with
speccing
one promise interface or whether we'd need to create one for each
type of promise.
Certainly the intent of promises is that there is exists only one
generic promise interface that can be reused everywhere, at
least from
the JS perspective, not sure if the extra type
[widgets] Draft Minutes for 4 March 2010 voice conference
The draft minutes from the March 4 Widgets voice conference are available at the following and copied below: http://www.w3.org/2010/03/04-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before March 18 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Regards, Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Widgets Voice Conference 04 Mar 2010 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0741.html See also: [3]IRC log [3] http://www.w3.org/2010/03/04-wam-irc Attendees Present Art, Bryan, Marcos, Robin, Arve, StevenP Regrets Marcin Chair Art Scribe Art Contents * [4]Topics 1. [5]Review and tweak agenda 2. [6]Announcements? 3. [7]PC spec: span element and dir attribute 4. [8]WARP spec 5. [9]URI scheme spec 6. [10]View Modes Media Feature spec 7. [11]AOB * [12]Summary of Action Items _ darobin joining in a split second! scribe ScribeNick: ArtB scribe Scribe: Art Date: 4 March 2010 Review and tweak agenda AB: the draft agenda was posted on March 3 ( [13]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/07 41.html ). Will add View Modes Media Features to the agenda since Robin posted an update today ( [14]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/07 45.html ). Any other change requests? [13] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0741.html [14] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0745.html Announcements? AB: I have one: No call next week on March 11; next call will be March 18. Any other short announcements? PC spec: span element and dir attribute AB: earlier this week Marcos submitted a proposal on how to address the span element and dir attribute ( [15]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/07 15.html ). [15] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0715.html MC: I'm waiting to see what the I18N WG says ... I added span and dir attr to the spec ... but I have not spec'ed he behavior ... we want to defer the proc model to a sepearate spec AB: is that proving to be problematic? MC: it's a bit complicated ... the bidi stuff that is ... if dir attr is set globally, need to set limits ... some stuff such as IRI interaction isn't clear ... for example name has a short name ... could have name in English and short name in Hebrew AB: are you having a diaglog with I18N group? MC: they were supposed to discuss it yesterday ... haven't seen their minutes yet ... Scott and Addison have been discussing it ... not clear how attrs are affected by direction AB: what's the prior art? MC: HTML5 ... but I think it is underspecified AB: other formats? MC: SVG is likely ... so we could check it AB: I would expect a lot of languages RB: SMIL, XForms, etc. darobin ... DocBook, TEI AB: can we minimize the changes to PC and defer all processing to the separate spec? MC: yes, that's the intent but not clear if we can get that ... when an impl gets back a dir string, it's got additional semantics in it SP: can't we just use CSS for this? ... CSS has a rule that matches bidi algorithm MC: there is no style associated with config.xml ... that is also discouraged in some places e.g. HTML5 ... the behavior we are looking for is indeed defined in CSS SP: can't we just say the text included behaves the same rules as CSS MC: yes, that is part of the solution ... but there are additional issues too AB: let's pause to see if the I18N WG has posted their minutes from yesterday's discussion MC: yes, sure AB: I just checked their archive and see no postings on March 3 or 4 Steven [16]http://www.w3.org/2010/03/03-pf-minutes.html [16] http://www.w3.org/2010/03/03-pf-minutes.html Steven is that it? AB: OK, so what is the plan of action MC: need to continue the investigation ... in my last email to them I asked them questions ... we need to get their answers scribe ACTION: barstow followup with Richard and Addison re the span and dir attribute discussions [recorded in [17]http://www.w3.org/2010/03/04-wam-minutes.html#action01] trackbot Created ACTION-506 - Followup with Richard and Addison re the span and dir attribute discussions [on Arthur Barstow - due 2010-03-11]. AB: the draft agenda includes a discussion on the Widget BiDi spec ... I presume there is no need to discuss that now MC: yes,
Re: [WARP] comment on subdomains
Hi Dom, On Dec 10, 2009, at 16:51 , Dominique Hazael-Massieux wrote: A quick comment after re-reading WARP at the invitation of Robin to DAP [1]: I don’t think the notion of subdomain is well-defined; is w3.org a subdomain of .org? is co a subdomain of co.uk? I assume they are in the sense of the spec, but if that’s so, it doesn’t match the “street” meaning of the word “subdomain”; this matters in particular in section 7 (rules for granting access), since this has an impact on how a user agent decides to grant access to a network resource. Given that IP addresses are allowed, the algorithm to determine if something is a subdomain of another domain is as simple as looking to the last dot in the authority component. That's a fair point. Would referencing RFC 1034 in that section address your concern? I would rather not have to define subdomain ourselves but rather reuse what already exists! (kudos on the spec otherwise; I find it to be very crisp) Thanks! -- Robin Berjon - http://berjon.com/
[widgets] Seeking pre-LCWD comments for View Modes Media Feature; deadline March 17
This is the start of a 2-week pre-LCWD call for comments re the View Modes Media Feature spec: http://dev.w3.org/2006/waf/widgets-vmmf/Overview.html If you have any comments, please send them to public-webapps@w3.org by March 17. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] Additionally, a LCWD should be considered feature-complete with all issues resolved. We will explicitly ask the CSS WG (via the www-style mail list) for comments. If there are other groups that should be asked for comments, please forward this email to them or identify the group(s). -Art Barstow Begin forwarded message: From: ext Robin Berjon ro...@berjon.com Date: March 4, 2010 8:13:17 AM EST To: public-webapps WG public-webapps@w3.org Subject: VMMF — new version Archived-At: http://www.w3.org/mid/ 1da7a886-141b-46ff-9ff7-6baa6cc6e...@berjon.com Hi all, I just produced an update of VMMF to make it ready for publication: http://dev.w3.org/2006/waf/widgets-vmmf/. Essentially I changed it so that it corresponds to CSS Media Queries. That, plus it being a UI oriented specification, means that there's only one normative assertion and it's a SHOULD. Comments welcome, I think that this baby can ship. -- Robin Berjon - http://berjon.com/
Re: Event handlers - Pointer Devices
Hi, Bryan- SULLIVAN, BRYAN L (ATTCINW) wrote (on 3/4/10 9:15 AM): This might be better discussed by the DAP group, as it's clearly a device API topic. By that definition, a mouse would be a device. :) This work belongs in the WebApps WG, and it is explicitly mentioned in our charter, to be taken up during our next charter period. DAP is not focused on user-input devices, more on things like cameras, calendars, etc. available on the local device. Also it would be interesting to hear from Apple and Wacom (without unnecessary details at this point), what areas of touch interface capabilities would be problematic for W3C to create API's for, from an IPR perspective (i.e. that would probably result in exclusions)... this concern is driven e.g. by the current touch-related issue between Apple and HTC. This is putting the cart before the horse. It's not appropriate to discuss IPR at this point, since we don't even have a draft spec (by design). Once we have a draft of the spec, participants who have IPR can have their legal team look at it and chime in at that point (though this may take place in Member space, since they may wish to do so under the legal framework of W3C Member confidentiality). I am concerned that it may not be fruitful, and may be counterproductive, for us to start speculating on this list about IPR. Let's keep the discussion on technical matters, please. However, use cases and requirements would be appropriate to discuss, and this should help frame a successful outcome for this spec. [1] http://www.w3.org/2009/05/DeviceAPICharter Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: [WARP] comment on subdomains
Le jeudi 04 mars 2010 à 15:51 +0100, Robin Berjon a écrit : On Dec 10, 2009, at 16:51 , Dominique Hazael-Massieux wrote: A quick comment after re-reading WARP at the invitation of Robin to DAP [1]: I don’t think the notion of subdomain is well-defined; is w3.org a subdomain of .org? is co a subdomain of co.uk? I assume they are in the sense of the spec, but if that’s so, it doesn’t match the “street” meaning of the word “subdomain”; this matters in particular in section 7 (rules for granting access), since this has an impact on how a user agent decides to grant access to a network resource. Given that IP addresses are allowed, the algorithm to determine if something is a subdomain of another domain is as simple as looking to the last dot in the authority component. That's a fair point. Would referencing RFC 1034 in that section address your concern? I would rather not have to define subdomain ourselves but rather reuse what already exists! Sounds good to me, although I think I would also rephrase somewhat the algorithm, à la: * the URI's scheme component is the same as scheme; and * if subdomains is false or if the URI's host component is not a domain name (as defined in RFC1034), the URI's host component is the same as host; or * if subdomains is true, the URI's host component is either the same as host, or is a subdomain of host (as defined in RFC1034); and * ... Dom
RE: Event handlers - Pointer Devices
OK, I agree, let's see a draft horse first, then later we can decide if it was worth dressing it up for the cart. On the main (or more useful) point perhaps, I think the distinction between a device's internal features, its peripherals as attached features, and more abstracted (even remote) resources is still very blurry between Webapps and DAP. For example, DAP is considering whether to represent device API's (called device here only because in some instances the resource provider might be local to the device) using an abstracted RESTful model (Powerbox) that I have asserted fits better in the Web API work in Webapps, because it's more aligned with the RESTful model of remote resource access over HTTP. And here we have consideration of screen input and mouse events, which are resources of the host device, at least when attached to it. I'd like to see some clearer distinction between the charters on these points. Thanks, Bryan Sullivan | ATT -Original Message- From: Doug Schepers [mailto:schep...@w3.org] Sent: Thursday, March 04, 2010 7:08 AM To: SULLIVAN, BRYAN L (ATTCINW) Cc: Charles Pritchard; public-webapps@w3.org Subject: Re: Event handlers - Pointer Devices Hi, Bryan- SULLIVAN, BRYAN L (ATTCINW) wrote (on 3/4/10 9:15 AM): This might be better discussed by the DAP group, as it's clearly a device API topic. By that definition, a mouse would be a device. :) This work belongs in the WebApps WG, and it is explicitly mentioned in our charter, to be taken up during our next charter period. DAP is not focused on user-input devices, more on things like cameras, calendars, etc. available on the local device. Also it would be interesting to hear from Apple and Wacom (without unnecessary details at this point), what areas of touch interface capabilities would be problematic for W3C to create API's for, from an IPR perspective (i.e. that would probably result in exclusions)... this concern is driven e.g. by the current touch-related issue between Apple and HTC. This is putting the cart before the horse. It's not appropriate to discuss IPR at this point, since we don't even have a draft spec (by design). Once we have a draft of the spec, participants who have IPR can have their legal team look at it and chime in at that point (though this may take place in Member space, since they may wish to do so under the legal framework of W3C Member confidentiality). I am concerned that it may not be fruitful, and may be counterproductive, for us to start speculating on this list about IPR. Let's keep the discussion on technical matters, please. However, use cases and requirements would be appropriate to discuss, and this should help frame a successful outcome for this spec. [1] http://www.w3.org/2009/05/DeviceAPICharter Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: [widgets] Request for Comments: LCWD of Widget Access Request Policy spec; deadline 13-Jan-2010
Hi Marcos, On Dec 21, 2009, at 16:06 , Marcos Caceres wrote: An access request is a request made by an author to the user agent for the ability to retrieve one or more network resources. The network resources and author requests to access are identified using access elements in the widget's configuration document. I gots me confused by the second sentence, maybe change to: Requests by an author to access network resources can be identified by the presence of access elements in the widget's configuration document. Sounds just as confused to me. How about: Access element in the widget's configuration document express the author's requests to access network resources. ? 3. Conformance This specification defines conformance criteria that apply to a single product: user agents that implement the interfaces that it contains. It's confusing to talk about interfaces here, though I understand you are talking about interfaces in general terms. I would prefer if the spec just said: This specification defines conformance criteria that apply to a single product: user agents. And a user agent be defined as a software application that implements this specification and the [WIDGETS] specification and it's dependencies. Okay. A user agent enforces an access request policy. In the default policy, a user agent must deny access to network resources external to the widget by default, whether this access is requested through APIs (e.g. XMLHttpRequest) or through markup (e.g. iframe, script, img). i think you need to make it really clear that you've just defined the default policy for a WUA. Please make it a sub-section or something. A subsection seems overkill for a single sentence. I'll split it into its own paragraph and make sure it's a dfn. The exact rules defining which execution scope applies to network resources loaded into a document running in the widget execution scope depend on the language that is being used inside the the widget. Typo: the the Okay. 5. The access Element Context in which this element may be used: PC uses Context in which this element is used:. It would be nice if this one said the same thing :) Okay! 5.1 Attributes origin An IRI attribute that defines the specifics of the access request that is requested. that is requested seems tautological... and makes the sentence read funny (and not ha ha funny.) I'll make it that is made. Additionally, an author can use the special value of U+002A ASTERISK (*): Okay. This special value provides a means for an author to request from the user agent unrestricted access to network resources. Break here. It's HAMMERTIME! Only the scheme and authority components can be present in the IRI that this attribute contains ([URI], [RFC3987]). I'm really sorry, I'm having a hard time parsing the above sentence. At first, I thought it was related to the sentence about *. Can you change the order of these sentences above. Also, the * value is pretty important, maybe it deserves it's own sub-section even if it just contains one short paragraph. i'm sure people will come back asking for clarification once we go to CR as to how it's supposed to work. I'll split and clarify. subdomains A boolean attribute that indicates whether or not the host component part of the access request applies to subdomains of domain in the origin attribute. It should be clear that subdomains and domain here refers to components of RFC-such-and-such, right? Yup, adding a reference to RFC 1034. The default value when this attribute is absent is false, meaning that access to subdomains is not requested. what does it means when I have: access domain=http://foo.bar.woo.com; subdomains=true/ Everything before woo.com is allowed, right? Maybe could be clear in the spec for people like me :) Err no, everything below foo.bar.woo.com. Maybe after reading RFC 1034 it'll be clearer? A domain is a subdomain of another domain if it is contained within that domain. This relationship can be tested by seeing if the subdomain's name ends with the containing domain's name. For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and . 5.2 Usage example This example contains multiple uses of the access element (not contained in the same configuration as the last one would make the others useless). The above sentence doesn't tell me anything (that I can understand) about the example. It be nice if it told me what I was looking at a bit more. Maybe you need to break this up into multiple examples, showing when it would be appropriate to use *. I'll clarify it somewhat (though it seems perfectly clear to me — it's several examples of the element!). They presume that http://www.w3.org/ns/widgets is the default namespace defined in their context: Instead of the fancy sentence above, why don't you just add a widget xmlns=... around the access elements? Because that would make a
Re: [WARP] comment on subdomains
On Mar 4, 2010, at 16:07 , Dominique Hazael-Massieux wrote: Le jeudi 04 mars 2010 à 15:51 +0100, Robin Berjon a écrit : On Dec 10, 2009, at 16:51 , Dominique Hazael-Massieux wrote: A quick comment after re-reading WARP at the invitation of Robin to DAP [1]: I don’t think the notion of subdomain is well-defined; is w3.org a subdomain of .org? is co a subdomain of co.uk? I assume they are in the sense of the spec, but if that’s so, it doesn’t match the “street” meaning of the word “subdomain”; this matters in particular in section 7 (rules for granting access), since this has an impact on how a user agent decides to grant access to a network resource. Given that IP addresses are allowed, the algorithm to determine if something is a subdomain of another domain is as simple as looking to the last dot in the authority component. That's a fair point. Would referencing RFC 1034 in that section address your concern? I would rather not have to define subdomain ourselves but rather reuse what already exists! Sounds good to me, although I think I would also rephrase somewhat the algorithm, à la: * the URI's scheme component is the same as scheme; and * if subdomains is false or if the URI's host component is not a domain name (as defined in RFC1034), the URI's host component is the same as host; or * if subdomains is true, the URI's host component is either the same as host, or is a subdomain of host (as defined in RFC1034); and Good suggestion, the latest ED reflects the above change plus another reference where subdomains are defined. Please let us know if that works for you! -- Robin Berjon - http://berjon.com/
Re: [WARP] comment on subdomains
1034 sounds like the appropriate normative reference for this sort of thing. -- Thomas Roessler, W3C t...@w3.org On 4 Mar 2010, at 15:51, Robin Berjon wrote: Hi Dom, On Dec 10, 2009, at 16:51 , Dominique Hazael-Massieux wrote: A quick comment after re-reading WARP at the invitation of Robin to DAP [1]: I don’t think the notion of subdomain is well-defined; is w3.org a subdomain of .org? is co a subdomain of co.uk? I assume they are in the sense of the spec, but if that’s so, it doesn’t match the “street” meaning of the word “subdomain”; this matters in particular in section 7 (rules for granting access), since this has an impact on how a user agent decides to grant access to a network resource. Given that IP addresses are allowed, the algorithm to determine if something is a subdomain of another domain is as simple as looking to the last dot in the authority component. That's a fair point. Would referencing RFC 1034 in that section address your concern? I would rather not have to define subdomain ourselves but rather reuse what already exists! (kudos on the spec otherwise; I find it to be very crisp) Thanks! -- Robin Berjon - http://berjon.com/
Re: [widgets] Request for Comments: LCWD of Widget Access Request Policy spec; deadline 13-Jan-2010
For the sake of the disposition of comments, I consider my comments disposed of (in a good way) :) Kind regards, Marcos On 4/03/10 4:28 PM, Robin Berjon wrote: Hi Marcos, On Dec 21, 2009, at 16:06 , Marcos Caceres wrote: An access request is a request made by an author to the user agent for the ability to retrieve one or more network resources. The network resources and author requests to access are identified using access elements in the widget's configuration document. I gots me confused by the second sentence, maybe change to: Requests by an author to access network resources can be identified by the presence of access elements in the widget's configuration document. Sounds just as confused to me. How about: Access element in the widget's configuration document express the author's requests to access network resources. ? Good enough. 3. Conformance This specification defines conformance criteria that apply to a single product: user agents that implement the interfaces that it contains. It's confusing to talk about interfaces here, though I understand you are talking about interfaces in general terms. I would prefer if the spec just said: This specification defines conformance criteria that apply to a single product: user agents. And a user agent be defined as a software application that implements this specification and the [WIDGETS] specification and it's dependencies. Okay. A user agent enforces an access request policy. In the default policy, a user agent must deny access to network resources external to the widget by default, whether this access is requested through APIs (e.g. XMLHttpRequest) or through markup (e.g. iframe, script, img). i think you need to make it really clear that you've just defined the default policy for a WUA. Please make it a sub-section or something. A subsection seems overkill for a single sentence. I'll split it into its own paragraph and make sure it's a dfn. Ok. The exact rules defining which execution scope applies to network resources loaded into a document running in the widget execution scope depend on the language that is being used inside the the widget. Typo: the the Okay. 5. The access Element Context in which this element may be used: PC uses Context in which this element is used:. It would be nice if this one said the same thing :) Okay! Great. 5.1 Attributes origin An IRI attribute that defines the specifics of the access request that is requested. that is requested seems tautological... and makes the sentence read funny (and not ha ha funny.) I'll make it that is made. Additionally, an author can use the special value of U+002A ASTERISK (*): Okay. This special value provides a means for an author to request from the user agent unrestricted access to network resources. Break here. It's HAMMERTIME! (Oh-oh-oh-oh-oh-oh-oh-oh-oh-oh-oh-oh) Only the scheme and authority components can be present in the IRI that this attribute contains ([URI], [RFC3987]). I'm really sorry, I'm having a hard time parsing the above sentence. At first, I thought it was related to the sentence about *. Can you change the order of these sentences above. Also, the * value is pretty important, maybe it deserves it's own sub-section even if it just contains one short paragraph. i'm sure people will come back asking for clarification once we go to CR as to how it's supposed to work. I'll split and clarify. subdomains A boolean attribute that indicates whether or not the host component part of the access request applies to subdomains of domain in the origin attribute. It should be clear that subdomains and domain here refers to components of RFC-such-and-such, right? Yup, adding a reference to RFC 1034. The default value when this attribute is absent is false, meaning that access to subdomains is not requested. what does it means when I have: access domain=http://foo.bar.woo.com; subdomains=true/ Everything before woo.com is allowed, right? Maybe could be clear in the spec for people like me :) Err no, everything below foo.bar.woo.com. Maybe after reading RFC 1034 it'll be clearer? A domain is a subdomain of another domain if it is contained within that domain. This relationship can be tested by seeing if the subdomain's name ends with the containing domain's name. For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and . 5.2 Usage example This example contains multiple uses of the access element (not contained in the same configuration as the last one would make the others useless). The above sentence doesn't tell me anything (that I can understand) about the example. It be nice if it told me what I was looking at a bit more. Maybe you need to break this up into multiple examples, showing when it would be appropriate to use *. I'll clarify it somewhat (though it seems perfectly clear to me — it's several examples of the element!). They presume that http://www.w3.org/ns/widgets is the
Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
On Thu, Mar 4, 2010 at 6:37 AM, Jeremy Orlow jor...@chromium.org wrote:
You are quite right! I misunderstood how this part of promises worked.
Is there excitement about speccing promises in general?
Yes. The starting point for a lot of the commonjs promises work is Tyler's
ref_send promise library, documented at
http://waterken.sourceforge.net/web_send/#Q. The commonjs work got more
complicated than this in order to try to accommodate legacy deferred-based
usage patterns within the same framework. While it may have helped adoption
within the commonjs community, IMO this extra complexity should not be in
any standard promise spec. Caja implements Tyler's spec without the extra
complexity, and we're quite happy with it.
I hope to work with Tyler and others to propose this to the EcmaScript
committee as part of a more general proposal for a communicating-event-loops
concurrency and distribution framework for future EcmaScript. Don't hold
your breath though, this is not yet even an EcmaScript strawman. Neither is
there any general consensus on the EcmaScript committee that EcmaScript
should be extended in these directions. In the meantime, I suggest just
using Tyler's ref_send and web_send libraries.
If not, it seems a little odd to spec such a powerful mechanism into just
IndexedDBand it might be best to spec the simplified version of
.then(): .then() will return undefined, onsuccess/onerror's return values
will be swallowed, and any thrown exceptions will be thrown.
This should make it easy to make IndexedDB support full blown promises
if/whenever they're specced. (It's not clear to me whether UA support for
them would offer enough advantages to warrant it.)
Note that ref_send exposes the .then() style functionality as a static
.when() method on Q rather than an instance .then() method on promises. This
is important, as it 1) allows resolved values to be used where a promise is
expected, and 2) it protects the caller from interleavings happening during
their Q.when() call, even if the alleged promise they are operating on is
something else.
It sounds like you're OK with such an approach, Kris?
What do others think?
J
In terms of speccing, I'm not sure if we can get away with
speccing
one promise interface or whether we'd need to create one for each
type of promise.
Certainly the intent of promises is that there is exists only one
generic promise interface that can be reused everywhere, at
least from
the JS perspective, not sure if the extra type constraints in IDL
demand multiple interfaces to model promise's effectively
parameterized generic type form.
Unfortunately, I don't really know. Before we try speccing it, I'll
definitely see if any WebIDL experts have suggestions.
Also, do we want to explicitly spec what happens in the following case?
window.indexedDB.open(...).then(
function(db) { db.openObjectStore(a).then( function(os) {
alert(Opened a); } ) }
).then(
function(db) { alert(Second db opened); }
);
Clearly the first function(db) is called first. But the question is
whether it'd be a race of which alert is called first or whether the
Second db opened alert should always be shown first (since clearly
if the first is called, the second _can_ be fired immediately
afterwards).
I'm on the fence about whether it'd be useful to spec that the
entire chain needs to be called one after the other before calling
any other callbacks. Does anyone have thoughts on whether this is
useful or not? If we do spec it to call the entire chain, then what
happens if inside one of the callbacks, something is added to the
chain (via another .then() call).
Specing the order of multiple events in the event loop seems like it
would be excessive burden on implementors, IMO.
I've been talking to a co-worker here who seems to know a decent
amount about promises (as implemented in E) and some about differed
(as implemented in Python's Twisted library). From talking to him,
it seems that my original suggestion for not handling exceptions
thrown inside a .then() callback is the way to go.
It seems as though promises put a lot of weight on composability and
making it so that the order of .then() calls not mattering. This
means that you can then pass promises to other async interfaces and
not have to worry about different timings leading to different
results. It also means that if you pass a promise into multiple
consumers (say, javascript libraries) you don't need to worry about
one using a promise in a way that screws up another.
Differed seems to be more expressive and flexible. For example,
instead of doing this:
window.indexedDB.open(...).then(
function(db) { db.openObjectStore(a).then(
function(os) { os.get(x).then(
function(value) { alert(Value: + value); }
) }
Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/4/2010 10:35 AM, Mark S. Miller wrote: On Thu, Mar 4, 2010 at 6:37 AM, Jeremy Orlow jor...@chromium.org mailto:jor...@chromium.org wrote: You are quite right! I misunderstood how this part of promises worked. Is there excitement about speccing promises in general? Yes. The starting point for a lot of the commonjs promises work is Tyler's ref_send promise library, documented at http://waterken.sourceforge.net/web_send/#Q. The commonjs work got more complicated than this in order to try to accommodate legacy deferred-based usage patterns within the same framework. While it may have helped adoption within the commonjs community, IMO this extra complexity should not be in any standard promise spec. Caja implements Tyler's spec without the extra complexity, and we're quite happy with it. I hope to work with Tyler and others to propose this to the EcmaScript committee as part of a more general proposal for a communicating-event-loops concurrency and distribution framework for future EcmaScript. Don't hold your breath though, this is not yet even an EcmaScript strawman. Neither is there any general consensus on the EcmaScript committee that EcmaScript should be extended in these directions. In the meantime, I suggest just using Tyler's ref_send and web_send libraries. It would be great if promises become first class, but obviously the IndexedDB specification can't be dependent on someone's JS library. If not, it seems a little odd to spec such a powerful mechanism into just IndexedDBand it might be best to spec the simplified version of .then(): .then() will return undefined, onsuccess/onerror's return values will be swallowed, and any thrown exceptions will be thrown. This should make it easy to make IndexedDB support full blown promises if/whenever they're specced. (It's not clear to me whether UA support for them would offer enough advantages to warrant it.) Note that ref_send exposes the .then() style functionality as a static .when() method on Q rather than an instance .then() method on promises. This is important, as it 1) allows resolved values to be used where a promise is expected, and 2) it protects the caller from interleavings happening during their Q.when() call, even if the alleged promise they are operating on is something else. The .then() function is in no way intended to be a replacement for a static .when() function. In contrast to ref_send, having promises defined by having a .then() function is in lieu of ref_send's definition of a promise where the promise is a function that must be called: promise(WHEN, callback, errback); This group can consider it an API like this, but I don't think that IndexedDB or any other W3C API would want to define promises in that way, as it is pretty awkward. Using .then() based promises in no way precludes the use of Q.when() implementations which meet both your criteria for safe operation. However, these can easily be implemented in JS, and I don't think the IndexedDB API needs to worry about such promise libraries. - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuP8f0ACgkQ9VpNnHc4zAwm9gCfajBUy0PZpaxvSctlorVeYIsK yQwAnAwtSd6BWPbpOOJTniZcojmNFQtw =GHjA -END PGP SIGNATURE-
Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
On Thu, Feb 18, 2010 at 4:31 AM, Jeremy Orlow jor...@google.com wrote: On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp k...@sitepen.com wrote: * Use promises for async interfaces - In server side JavaScript, most projects are moving towards using promises for asynchronous interfaces instead of trying to define the specific callback parameters for each interface. I believe the advantages of using promises over callbacks are pretty well understood in terms of decoupling async semantics from interface definitions, and improving encapsulation of concerns. For the indexed database API this would mean that sync and async interfaces could essentially look the same except sync would return completed values and async would return promises. I realize that defining a promise interface would have implications beyond the indexed database API, as the goal of promises is to provide a consistent interface for asynchronous interaction across components, but perhaps this would be a good time for the W3C to define such an API. It seems like the indexed database API would be a perfect interface to leverage promises. If you are interested in proposal, there is one from CommonJS here [1] (the get() and call() wouldn't apply here). With this interface, a promise.then(callback, errorHandler) function is the only function a promise would need to provide. [1] http://wiki.commonjs.org/wiki/Promises Very interesting. The general concept seems promising and fairly flexible. You can easily code in a similar style to normal async/callback semantics, but it seems like you have a lot more flexibility. I do have a few questions though. Are there any good examples of these used in the wild that you can point me towards? I used my imagination for prototyping up some examples, but it'd be great to see some real examples + be able to see the exact semantics used in those implementations. I see that you can supply an error handling callback to .then(), but does that only apply to the one operation? I could easily imagine emulating try/catch type semantics and have errors continue down the line of .then's until someone handles it. It might even make sense to allow the error handlers to re-raise (i.e. allow to bubble) errors so that later routines would get them as well. Maybe you'd even want it to bubble by default? What have other implementations done with this stuff? What is the most robust and least cumbersome for typical applications? (And, in te complete absence of real experience, are there any expert opinions on what might work?) Overall this seems fairly promising and not that hard to implement. Do others see pitfalls that I'm missing? J I disagree that IndexedDB should use promises, for several reasons: * Promises are only really useful when they are used ubiquitously throughout the platform, so that you can pass them around like references. In libraries like Dojo, MochiKit, and Twisted, this is exactly the situation. But in the web platform, this would be the first such API. Without places to pass a promise to, all you really have is a lot of additional complexity. * ISTM that the entire space is still evolving quite rapidly. Many JavaScript libraries have implemented a form of this, and this proposal is also slightly different from any of them. I think it is premature to have browsers implement this while library authors are still hashing out best practice. Once it is in browsers, it's forever. * There is nothing preventing JS authors from implementing a promise-style API on top of IndexedDB, if that is what they want to do. - a
Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
On Thu, Mar 4, 2010 at 5:46 PM, Kris Zyp k...@sitepen.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/4/2010 10:35 AM, Mark S. Miller wrote: On Thu, Mar 4, 2010 at 6:37 AM, Jeremy Orlow jor...@chromium.org mailto:jor...@chromium.org jor...@chromium.org wrote: You are quite right! I misunderstood how this part of promises worked. Is there excitement about speccing promises in general? Yes. The starting point for a lot of the commonjs promises work is Tyler's ref_send promise library, documented at http://waterken.sourceforge.net/web_send/#Qhttp://waterken.sourceforge.net/web_send/#Q. The commonjs work got more complicated than this in order to try to accommodate legacy deferred-based usage patterns within the same framework. While it may have helped adoption within the commonjs community, IMO this extra complexity should not be in any standard promise spec. Caja implements Tyler's spec without the extra complexity, and we're quite happy with it. I hope to work with Tyler and others to propose this to the EcmaScript committee as part of a more general proposal for a communicating-event-loops concurrency and distribution framework for future EcmaScript. Don't hold your breath though, this is not yet even an EcmaScript strawman. Neither is there any general consensus on the EcmaScript committee that EcmaScript should be extended in these directions. In the meantime, I suggest just using Tyler's ref_send and web_send libraries. It would be great if promises become first class, but obviously the IndexedDB specification can't be dependent on someone's JS library. If not, it seems a little odd to spec such a powerful mechanism into just IndexedDBand it might be best to spec the simplified version of .then(): .then() will return undefined, onsuccess/onerror's return values will be swallowed, and any thrown exceptions will be thrown. This should make it easy to make IndexedDB support full blown promises if/whenever they're specced. (It's not clear to me whether UA support for them would offer enough advantages to warrant it.) Note that ref_send exposes the .then() style functionality as a static .when() method on Q rather than an instance .then() method on promises. This is important, as it 1) allows resolved values to be used where a promise is expected, and 2) it protects the caller from interleavings happening during their Q.when() call, even if the alleged promise they are operating on is something else. Thanks a lot for your feedback! This is very valuable and definitely provided some food for thought. I started working on a rambly email about the pro's and cons of when when I saw Kris's response. The .then() function is in no way intended to be a replacement for a static .when() function. In contrast to ref_send, having promises defined by having a .then() function is in lieu of ref_send's definition of a promise where the promise is a function that must be called: promise(WHEN, callback, errback); This group can consider it an API like this, but I don't think that IndexedDB or any other W3C API would want to define promises in that way, as it is pretty awkward. Using .then() based promises in no way precludes the use of Q.when() implementations which meet both your criteria for safe operation. However, these can easily be implemented in JS, and I don't think the IndexedDB API needs to worry about such promise libraries. Which is basically what I had arrived at in my mind as well. It'll definitely be interesting to see how the EMCAScript side of promises shapes up. But in the mean time, I think the simpler version that we've been discussing will be a good balance of features but minimized API surface area...and keeping chances high that what ends up being standardized would fit in well with the API. At this point, I feel fairly confident that using a scaled down version of promises would work well in IndexedDB. But, at the same time, a callback based API would be much more standard and it wouldn't be that hard for someone to build a promise based library around IndexedDB. Nikunj, Pablo, Mozilla, etc...what do you think is the best way forward here? Should we give scaled back promises a shot? Or should we just go with a callback based approach? J Summary of what I'm currently thinking we should do, if we go with a Promises type async API: Each async function would return a promise. A promise has one method: .then(). Then takes up to two callbacks. The first is onsuccess. The second is onerror. You can call .then() before and after the async call has finished--in fact, there's no way to know for sure whether it has finished before you call .then() (but that's fine). If you pass in garbage to the callbacks, it'll throw an exception, but null/undefined and omitting them is fine. When the promise is ready to fire the callbacks, it'll always do it
Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/4/2010 11:08 AM, Aaron Boodman wrote: On Thu, Feb 18, 2010 at 4:31 AM, Jeremy Orlow jor...@google.com wrote: On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp k...@sitepen.com wrote: * Use promises for async interfaces - In server side JavaScript, most projects are moving towards using promises for asynchronous interfaces instead of trying to define the specific callback parameters for each interface. I believe the advantages of using promises over callbacks are pretty well understood in terms of decoupling async semantics from interface definitions, and improving encapsulation of concerns. For the indexed database API this would mean that sync and async interfaces could essentially look the same except sync would return completed values and async would return promises. I realize that defining a promise interface would have implications beyond the indexed database API, as the goal of promises is to provide a consistent interface for asynchronous interaction across components, but perhaps this would be a good time for the W3C to define such an API. It seems like the indexed database API would be a perfect interface to leverage promises. If you are interested in proposal, there is one from CommonJS here [1] (the get() and call() wouldn't apply here). With this interface, a promise.then(callback, errorHandler) function is the only function a promise would need to provide. [1] http://wiki.commonjs.org/wiki/Promises Very interesting. The general concept seems promising and fairly flexible. You can easily code in a similar style to normal async/callback semantics, but it seems like you have a lot more flexibility. I do have a few questions though. Are there any good examples of these used in the wild that you can point me towards? I used my imagination for prototyping up some examples, but it'd be great to see some real examples + be able to see the exact semantics used in those implementations. I see that you can supply an error handling callback to .then(), but does that only apply to the one operation? I could easily imagine emulating try/catch type semantics and have errors continue down the line of .then's until someone handles it. It might even make sense to allow the error handlers to re-raise (i.e. allow to bubble) errors so that later routines would get them as well. Maybe you'd even want it to bubble by default? What have other implementations done with this stuff? What is the most robust and least cumbersome for typical applications? (And, in te complete absence of real experience, are there any expert opinions on what might work?) Overall this seems fairly promising and not that hard to implement. Do others see pitfalls that I'm missing? J I disagree that IndexedDB should use promises, for several reasons: * Promises are only really useful when they are used ubiquitously throughout the platform, so that you can pass them around like references. In libraries like Dojo, MochiKit, and Twisted, this is exactly the situation. But in the web platform, this would be the first such API. Without places to pass a promise to, all you really have is a lot of additional complexity. I certainly agree that promises are more useful when used ubiquitously. However, promises have many advantages besides just being a common interface for asynchronous operations, including interface simplicity, composibility, and separation of concerns. But, your point about this being the first such API is really important. If we are going to use promises in the IndexedDB, I think they should the webapps group should be looking at them beyond the scope of just the IndexedDB API, and how they could be used in other APIs, such that common interface advantage could be realized. Looking at the broad perspective is key here. * ISTM that the entire space is still evolving quite rapidly. Many JavaScript libraries have implemented a form of this, and this proposal is also slightly different from any of them. I think it is premature to have browsers implement this while library authors are still hashing out best practice. Once it is in browsers, it's forever. Promises have been around for a number of years, we already have a lot of experience to draw from, this isn't exactly a brand new idea, promises are a well-established concept. The CommonJS proposal is nothing ground breaking, it is more based on the culmination of ideas of Dojo, ref_send and others. It is also worth noting that a number of JS libraries have expressed interest in moving towards the CommonJS promise proposal, and Dojo will probably support them in 1.5. * There is nothing preventing JS authors from implementing a promise-style API on top of IndexedDB, if that is what they want to do. Yes, you can always make an API harder to use so that JS authors have more they can do with it ;). But it is true, we can build promises on top of an plain event-based
Re: Event handlers - Pointer Devices
On the main (or more useful) point perhaps, I think the distinction between a device's internal features, its peripherals as attached features, and more abstracted (even remote) resources is still very blurry between Webapps and DAP. ... Bryan Sullivan | ATT Perhaps the System Information and Events API section of the DAP charter should be two separate items. It seems to me that Events are the cause of the confusion here; and they are complex. The charter summary doesn't mention that most of the protocol APIs could trigger events. For instance: Many Cameras will be supporting simple image recognition of 2d barcodes; onbarcode() would, for instance, be an event. such an event would likely be in the DAP charter, not in the WebApps charter (am I wrong?). Additional events would encompass the current device APIs ( oncamerastart, ontaskadded, onnetworkunreachable, etc ). The DAP really seems quite restricted to PIMs, which is surprising. Where do measurement accessories such as accelerometer, thermometer, compass, and other measurement services fit? From: Doug Schepers ... DAP is not focused on user-input devices, more on things like cameras, calendars, etc. available on the local device. I am concerned that it may not be fruitful, and may be counterproductive, for us to start speculating on this list about IPR. Let's keep the discussion on technical matters, please. ... However, use cases and requirements would be appropriate to discuss, and this should help frame a successful outcome for this spec. ... [1] http://www.w3.org/2009/05/DeviceAPICharter Well, I'd like to speculate a little: touch is not patented but gesture recognition is. Working within that framework gives us a firm scope: onpressurechange is a touch event, onPsychicRaysOfIntent is something that can be left up to a mechanism detailed by the Device API group. Gestures may well belong to a persons personal device profile. I've seen requests for ondeviceshake, onpinch, but I fear that implementations might run afoul of existing IP. There are also better names, that target their typical functionality: onpinch is often used to trigger a zoom command; onzoom (or a borrowing from SVG), would allow for the same functionality, without suggesting a gesture recognition system. I realize that it'd be far easier to write some applications if these high level APIs were part of every implementation, but I think they are too risky. What is a pinch, what threshold should a shake have? These are details to be left to individual implementations. Let's sidestep the issue early. -Charles
[widgets] IESG Approved Media Type application/widget
FYI (subject says it all). Begin forwarded message: From: ext Alexey Melnikov alexey.melni...@isode.com Date: March 4, 2010 1:19:33 PM EST To: Philippe Le Hegaret p...@w3.org Cc: i...@ietf.org i...@ietf.org, marc...@opera.com marc...@opera.com, public-ietf-...@w3.org public-ietf- w...@w3.org, Dan Connolly conno...@w3.org Subject: Re: Requesting IESG Approval for the Media Type application/widget Archived-At: http://www.w3.org/mid/4b8ff9b5.3020...@isode.com Philippe Le Hegaret wrote: Dear IESG participants, This message is to request approval for the registration of the media type application/widget, as described in an appendix of Widget Packaging and Configuration: http://www.w3.org/TR/widgets/#media-type-registration-for- applicationw This message follows the procedure described in the Media Type Specifications and Registration Procedures, section 5.2, IESG Approval [1]. The proposed media type were sent for preliminary community review on October 28, 2008: http://www.alvestrand.no/pipermail/ietf-types/2009-October/ 002275.html No comments were received during the review period. We believe the media type is now ready for IESG approval. This was approved by IESG today. An official announcement should be sent out early next week. Thank you, Philippe [1] http://www.ietf.org/rfc/rfc4288.txt -- IETF Application Area Director, http://www.ietf.org/IESGmems.html Internet Messaging Team Lead, http://www.isode.com JID: same as my email address
Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
On Mar 4, 2010, at 10:23 AM, Kris Zyp wrote: On 3/4/2010 11:08 AM, Aaron Boodman wrote: On Thu, Feb 18, 2010 at 4:31 AM, Jeremy Orlow jor...@google.com wrote: On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp k...@sitepen.com wrote: * Use promises for async interfaces - In server side JavaScript, most projects are moving towards using promises for asynchronous interfaces instead of trying to define the specific callback parameters for each interface. I believe the advantages of using promises over callbacks are pretty well understood in terms of decoupling async semantics from interface definitions, and improving encapsulation of concerns. For the indexed database API this would mean that sync and async interfaces could essentially look the same except sync would return completed values and async would return promises. I realize that defining a promise interface would have implications beyond the indexed database API, as the goal of promises is to provide a consistent interface for asynchronous interaction across components, but perhaps this would be a good time for the W3C to define such an API. It seems like the indexed database API would be a perfect interface to leverage promises. If you are interested in proposal, there is one from CommonJS here [1] (the get() and call() wouldn't apply here). With this interface, a promise.then(callback, errorHandler) function is the only function a promise would need to provide. [1] http://wiki.commonjs.org/wiki/Promises Very interesting. The general concept seems promising and fairly flexible. You can easily code in a similar style to normal async/callback semantics, but it seems like you have a lot more flexibility. I do have a few questions though. Are there any good examples of these used in the wild that you can point me towards? I used my imagination for prototyping up some examples, but it'd be great to see some real examples + be able to see the exact semantics used in those implementations. I see that you can supply an error handling callback to .then(), but does that only apply to the one operation? I could easily imagine emulating try/catch type semantics and have errors continue down the line of .then's until someone handles it. It might even make sense to allow the error handlers to re-raise (i.e. allow to bubble) errors so that later routines would get them as well. Maybe you'd even want it to bubble by default? What have other implementations done with this stuff? What is the most robust and least cumbersome for typical applications? (And, in te complete absence of real experience, are there any expert opinions on what might work?) Overall this seems fairly promising and not that hard to implement. Do others see pitfalls that I'm missing? J I disagree that IndexedDB should use promises, for several reasons: * Promises are only really useful when they are used ubiquitously throughout the platform, so that you can pass them around like references. In libraries like Dojo, MochiKit, and Twisted, this is exactly the situation. But in the web platform, this would be the first such API. Without places to pass a promise to, all you really have is a lot of additional complexity. I certainly agree that promises are more useful when used ubiquitously. However, promises have many advantages besides just being a common interface for asynchronous operations, including interface simplicity, composibility, and separation of concerns. But, your point about this being the first such API is really important. If we are going to use promises in the IndexedDB, I think they should the webapps group should be looking at them beyond the scope of just the IndexedDB API, and how they could be used in other APIs, such that common interface advantage could be realized. Looking at the broad perspective is key here. In general, IndexedDB has taken an approach of leaving ease of programming to libraries. There seems to be a good case to build libraries to make asynchronous programming with IndexedDB easier through the use of such mechanisms as promises. In fact, IndexedDB might be yet another area for libraries to slug it out. * ISTM that the entire space is still evolving quite rapidly. Many JavaScript libraries have implemented a form of this, and this proposal is also slightly different from any of them. I think it is premature to have browsers implement this while library authors are still hashing out best practice. Once it is in browsers, it's forever. Promises have been around for a number of years, we already have a lot of experience to draw from, this isn't exactly a brand new idea, promises are a well-established concept. The CommonJS proposal is nothing ground breaking, it is more based on the culmination of ideas of Dojo, ref_send and others. It is also worth noting that a number of JS libraries have expressed interest in moving towards the CommonJS promise proposal, and Dojo will probably support them in 1.5. I feel that we should avoid
Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
On Thu, Mar 4, 2010 at 6:46 PM, Nikunj Mehta nik...@o-micron.com wrote: On Mar 4, 2010, at 10:23 AM, Kris Zyp wrote: On 3/4/2010 11:08 AM, Aaron Boodman wrote: On Thu, Feb 18, 2010 at 4:31 AM, Jeremy Orlow jor...@google.com wrote: On Wed, Jan 27, 2010 at 9:46 PM, Kris Zyp k...@sitepen.com wrote: * Use promises for async interfaces - In server side JavaScript, most projects are moving towards using promises for asynchronous interfaces instead of trying to define the specific callback parameters for each interface. I believe the advantages of using promises over callbacks are pretty well understood in terms of decoupling async semantics from interface definitions, and improving encapsulation of concerns. For the indexed database API this would mean that sync and async interfaces could essentially look the same except sync would return completed values and async would return promises. I realize that defining a promise interface would have implications beyond the indexed database API, as the goal of promises is to provide a consistent interface for asynchronous interaction across components, but perhaps this would be a good time for the W3C to define such an API. It seems like the indexed database API would be a perfect interface to leverage promises. If you are interested in proposal, there is one from CommonJS here [1] (the get() and call() wouldn't apply here). With this interface, a promise.then(callback, errorHandler) function is the only function a promise would need to provide. [1] http://wiki.commonjs.org/wiki/Promises Very interesting. The general concept seems promising and fairly flexible. You can easily code in a similar style to normal async/callback semantics, but it seems like you have a lot more flexibility. I do have a few questions though. Are there any good examples of these used in the wild that you can point me towards? I used my imagination for prototyping up some examples, but it'd be great to see some real examples + be able to see the exact semantics used in those implementations. I see that you can supply an error handling callback to .then(), but does that only apply to the one operation? I could easily imagine emulating try/catch type semantics and have errors continue down the line of .then's until someone handles it. It might even make sense to allow the error handlers to re-raise (i.e. allow to bubble) errors so that later routines would get them as well. Maybe you'd even want it to bubble by default? What have other implementations done with this stuff? What is the most robust and least cumbersome for typical applications? (And, in te complete absence of real experience, are there any expert opinions on what might work?) Overall this seems fairly promising and not that hard to implement. Do others see pitfalls that I'm missing? J I disagree that IndexedDB should use promises, for several reasons: * Promises are only really useful when they are used ubiquitously throughout the platform, so that you can pass them around like references. In libraries like Dojo, MochiKit, and Twisted, this is exactly the situation. But in the web platform, this would be the first such API. Without places to pass a promise to, all you really have is a lot of additional complexity. I certainly agree that promises are more useful when used ubiquitously. However, promises have many advantages besides just being a common interface for asynchronous operations, including interface simplicity, composibility, and separation of concerns. But, your point about this being the first such API is really important. If we are going to use promises in the IndexedDB, I think they should the webapps group should be looking at them beyond the scope of just the IndexedDB API, and how they could be used in other APIs, such that common interface advantage could be realized. Looking at the broad perspective is key here. In general, IndexedDB has taken an approach of leaving ease of programming to libraries. There seems to be a good case to build libraries to make asynchronous programming with IndexedDB easier through the use of such mechanisms as promises. In fact, IndexedDB might be yet another area for libraries to slug it out. * ISTM that the entire space is still evolving quite rapidly. Many JavaScript libraries have implemented a form of this, and this proposal is also slightly different from any of them. I think it is premature to have browsers implement this while library authors are still hashing out best practice. Once it is in browsers, it's forever. Promises have been around for a number of years, we already have a lot of experience to draw from, this isn't exactly a brand new idea, promises are a well-established concept. The CommonJS proposal is nothing ground breaking, it is more based on the culmination of ideas of Dojo, ref_send and others. It is also worth noting that a number of JS libraries
Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/4/2010 11:46 AM, Nikunj Mehta wrote: On Mar 4, 2010, at 10:23 AM, Kris Zyp wrote: On 3/4/2010 11:08 AM, Aaron Boodman wrote: [snip] * There is nothing preventing JS authors from implementing a promise-style API on top of IndexedDB, if that is what they want to do. Yes, you can always make an API harder to use so that JS authors have more they can do with it ;). You will agree that we don't want to wait for one style of promises to win out over others before IndexedDB can be made available to programmers. Till the soil and let a thousand flowers bloom. The IndexedDB spec isn't and can't just sit back and not define the asynchronous interface. Like it or not, IndexedDB has defined a promise-like entity with the |DBRequest| interface. Why is inventing a new (and somewhat ugly) flower better than designing based on the many flowers that have already bloomed? - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuQAiUACgkQ9VpNnHc4zAzZkgCeIjAVz56S3sR5BeKt8lZPGMJo 6rYAoJ4x4WJN9W9LhdXkbbJaT94A8/om =oJbA -END PGP SIGNATURE-
Re: [IndexedDB] Promises (WAS: Seeking pre-LCWD comments for Indexed Database API; deadline February 2)
On Mar 4, 2010, at 10:55 AM, Kris Zyp wrote: On 3/4/2010 11:46 AM, Nikunj Mehta wrote: On Mar 4, 2010, at 10:23 AM, Kris Zyp wrote: On 3/4/2010 11:08 AM, Aaron Boodman wrote: [snip] * There is nothing preventing JS authors from implementing a promise-style API on top of IndexedDB, if that is what they want to do. Yes, you can always make an API harder to use so that JS authors have more they can do with it ;). You will agree that we don't want to wait for one style of promises to win out over others before IndexedDB can be made available to programmers. Till the soil and let a thousand flowers bloom. The IndexedDB spec isn't and can't just sit back and not define the asynchronous interface. Like it or not, IndexedDB has defined a promise-like entity with the |DBRequest| interface. Why is inventing a new (and somewhat ugly) flower better than designing based on the many flowers that have already bloomed? I meant to say that the IndexedDB spec should be updated to use a model that supports promises. If the current one is not adequate then, by all means, let's make it. However, we don't need a full-fledged promises in IndexedDB. I hope you agree this time.
