CfC: publish LCWD of Widget Updates; deadline March 19
Marcos would like to publish a Last Call Working Draft of the Widget Updates spec and this is a CfC to do, using the following document as the basis: http://dev.w3.org/2006/waf/widgets-updates/pub/ This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. 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. ]] If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by March 19 at the latest. Positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. -AB
Re: Regarding app notification and wake up
On Fri, 09 Mar 2012 09:10:19 +0100, Stefan Hakansson LK stefan.lk.hakans...@ericsson.com wrote: The webrtc WG has identified that the ability to notify, and possibly wake up, a web application of incoming events is important. This to enable support of use cases such as incoming calls. And in certain scenarios the resource use (e.g. power) is very important. However, this kind of functionality is not in scope of the webrtc WG, but seems to belong to the Web Applications WG. So this is a message that the webrtc WG is interested in seeing technology that supports this being developed. We have also noted discussions in Web Apps around use cases for connection-less push: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0008.html - especially the third one is very relevant for us. Stefan and Harald (chairs) for the webrtc WG. In the current charter proposal (which is under review at the moment) we have [[[ Server-Sent Events An API for opening an HTTP connection for receiving push notifications from a server in the form of DOM events. The API is designed such that it can be extended to work with other push notification schemes such as Push SMS. ]]] - http://www.w3.org/2012/03/webapps-proposed-charter.html I'm not sure if that is enough, sounds like you would like something more. In which case the best thing is to get people who are interested in developing it to say so, through their review and in this working group. cheers Chaals -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan litt norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [DOM4] NodeList should be deprecated
On Thu, Mar 8, 2012 at 11:57 PM, Anne van Kesteren ann...@opera.com wrote: On Thu, 08 Mar 2012 23:24:45 +0100, Ojan Vafai o...@chromium.org wrote: Dynamic NodeLists have a significant memory and performance cost. Static NodeLists are basically just under-powered arrays. We should just return Node arrays from any new APIs that return a list of Nodes. I'd like to see NodeList get similar treatment to hasFeature, i.e. a note that it not be used for new APIs and possibly even the explicitly list the APIs allowed to return them. I don't see the Dynamic/Static distinction in DOM4 or the HTML spec. Is this specified anywhere? We use the words live and static. For reference, this came up in WebKit with some new Regions APIs https://bugs.webkit.org/show_**bug.cgi?id=80638https://bugs.webkit.org/show_bug.cgi?id=80638 . Mutation observers uses NodeList too. Though there's no reason they couldn't use arrays instead (they're not live). In fact, that would make the API more self-consistent, since arrays (of MutationRecords) are already part of the interface. - Adam
Re: [DOM4] NodeList should be deprecated
On Mon, Mar 12, 2012 at 2:00 PM, Adam Klein ad...@chromium.org wrote: On Thu, Mar 8, 2012 at 11:57 PM, Anne van Kesteren ann...@opera.comwrote: On Thu, 08 Mar 2012 23:24:45 +0100, Ojan Vafai o...@chromium.org wrote: Dynamic NodeLists have a significant memory and performance cost. Static NodeLists are basically just under-powered arrays. We should just return Node arrays from any new APIs that return a list of Nodes. I'd like to see NodeList get similar treatment to hasFeature, i.e. a note that it not be used for new APIs and possibly even the explicitly list the APIs allowed to return them. I don't see the Dynamic/Static distinction in DOM4 or the HTML spec. Is this specified anywhere? We use the words live and static. For reference, this came up in WebKit with some new Regions APIs https://bugs.webkit.org/show_**bug.cgi?id=80638https://bugs.webkit.org/show_bug.cgi?id=80638 . Mutation observers uses NodeList too. Though there's no reason they couldn't use arrays instead (they're not live). In fact, that would make the API more self-consistent, since arrays (of MutationRecords) are already part of the interface. The NodeList item() method is a blocker. Rick - Adam
Re: [DOM4] NodeList should be deprecated
On Mon, 12 Mar 2012 19:07:31 +0100, Rick Waldron waldron.r...@gmail.com wrote: The NodeList item() method is a blocker. Blocker in what way? -- Anne van Kesteren http://annevankesteren.nl/
Re: [DOM4] NodeList should be deprecated
On Mar 12, 2012, at 3:06 PM, Anne van Kesteren ann...@opera.com wrote: On Mon, 12 Mar 2012 19:07:31 +0100, Rick Waldron waldron.r...@gmail.com wrote: The NodeList item() method is a blocker. Blocker in what way? As I've always understood it - the item() method is what differentiates NodeList from Array and blocks it from being just an array. Is this incorrect? Rick -- Anne van Kesteren http://annevankesteren.nl/
Re: Regarding app notification and wake up
Le 9 mars 2012 à 19:43, SULLIVAN, BRYAN L a écrit : This is different from the earlier discussion on extending SSE to connectionless event sources, as there's no assumption the Webapp is running in this case. If the Webapp *is* running, it's within the scope of what we have discussed earlier as SSE extensions (and not technically a wakeup). If I understood the use case, it means that 1. the device is addressable (except for customers with a subscription to a Mobile Operator, not sure how we would do that. Any ideas? Maybe on local network that would be feasible but doesn't answer the use case it seems.) 2. the software is addressable (more than one software able to process a specific request. Think about Opera and Firefox on the same device.) 3. that also requires a strong authentication system I can see the appeal, but I balance it with spam at large scale too. The UX model of SSE is that the user is still initiating the call. Related to the initial mail http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0008 http://bkaj.net/w3c/eventsource-push.html -- Karl Dubost - http://dev.opera.com/ Developer Relations, Opera Software
RE: Regarding app notification and wake up
Karl, excellent questions. Re (1), there are various systems of device addressing in use today, largely dependent upon the notification delivery system. An assumption to start with is that barring any optimizations which enable seamless switching between SSE connections and connectionless delivery (which requires a delivery agent/client on the device, feasible but still an optimization - we can table that for now, in this discussion), is that the webapp coordinates whatever connectionless/shared delivery system is to be used along with the appropriate addressing scheme and address, with the webapp server prior to the switch (or in the setup of the original connection). Without getting too deep in to specific system designs I can say that this does work and can demo the concept pretty soon (I'm implementing a demo now). Re (2), since the webapp creates a specific eventsource object (using SSE as the model), there is a direct thread back to it from the user agent. What is needed for the user agent to deliver only the specific events that the webapp desires, is that there needs to be some filter criteria that is negotiated with the webapp server (or delivery system) e.g. as part of the original eventsource object creation. In OMA Push, we have an Application ID header that is used for this purpose (it can carry any arbitrary value, and be used by the user agent or a local Push Client to filter out events other than those desired). Webapps can also use any arbitrary application-layer data to filter or apply trust to incoming events, but this is a convenient thing to do by a UA or Push Client and that's why we included that in the OMA Push design. Other notification delivery systems probably have similar features. The goal is not however to reference delivery-system specific features directly in the W3C API, but to describe how such app addressability is possible in general, and at most to all generic filter criteria mechanisms to the API (e.g. this header equals that value, or more generically this token is present with that value). Re (3), I think the web authentication system (same-origin policy and CORS) is strong enough for what is needed here. Beyond that, apps can use any high-order security for authentication/authorization tokens to be included in the application data or as headers (in delivery systems that follow the HTTP header+body model, ala OMA Push). There's probably a lot in the above statements that need to be unpacked in more detail. That's why we proposed this for the charter update. We have been involved in Push-based enabler and service design since pre-2000, and with that background I think we have a good foundation to resolve the questions you noted. Thanks, Bryan Sullivan -Original Message- From: Karl Dubost [mailto:ka...@opera.com] Sent: Monday, March 12, 2012 2:04 PM To: SULLIVAN, BRYAN L Cc: Ian Hickson; Stefan Hakansson LK; public-webapps@w3.org Subject: Re: Regarding app notification and wake up Le 9 mars 2012 à 19:43, SULLIVAN, BRYAN L a écrit : This is different from the earlier discussion on extending SSE to connectionless event sources, as there's no assumption the Webapp is running in this case. If the Webapp *is* running, it's within the scope of what we have discussed earlier as SSE extensions (and not technically a wakeup). If I understood the use case, it means that 1. the device is addressable (except for customers with a subscription to a Mobile Operator, not sure how we would do that. Any ideas? Maybe on local network that would be feasible but doesn't answer the use case it seems.) 2. the software is addressable (more than one software able to process a specific request. Think about Opera and Firefox on the same device.) 3. that also requires a strong authentication system I can see the appeal, but I balance it with spam at large scale too. The UX model of SSE is that the user is still initiating the call. Related to the initial mail http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0008 http://bkaj.net/w3c/eventsource-push.html -- Karl Dubost - http://dev.opera.com/ Developer Relations, Opera Software
[Bug 9557] Mouse Lock via Javascript
https://www.w3.org/Bugs/Public/show_bug.cgi?id=9557 Travis Leithead [MSFT] tra...@microsoft.com changed: What|Removed |Added Keywords||needsReview Status|NEW |RESOLVED Resolution||LATER --- Comment #56 from Travis Leithead [MSFT] tra...@microsoft.com 2012-03-12 23:55:36 UTC --- Cool. Looks like this is well on its way. Since this doesn't need to be a DOM3 Events issue anymore, I'm resolving this bug. Please let me know if that is satisfactory. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 15720] [IndexedDB] Specify key generation details
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15720 Jonas Sicking jo...@sicking.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 16224] Change .readyState to use string values rather than numeric constants
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16224 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||WONTFIX --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2012-03-13 03:57:52 UTC --- While I agree with the design principle, I think it's not a big enough win to be worth the churn here. People complain all the time that we keep changing things — we should only do it when we have a truly compelling reason (e.g. a security problem). In practice, little non-debug code will likely end up using eventsource.readyState anyway. It's easier to use the events. It was mostly added for consistency with XMLHttpRequest, which also uses numbers — and people don't generally find it onerous to remember which readyState is which for that API. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 16223] Change .readyState to use string values rather than numeric constants
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16223 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@hixie.ch Resolution||WONTFIX --- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2012-03-13 03:57:26 UTC --- While I agree with the design principle, I think it's not a big enough win to be worth the churn here. People complain all the time that we keep changing things — we should only do it when we have a truly compelling reason (e.g. a security problem). In practice, little non-debug code will likely end up using websocket.readyState anyway. It's easier to use the events. It was mostly added for consistency with XMLHttpRequest, which also uses numbers — and people don't generally find it onerous to remember which readyState is which for that API. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
