Re: Rechartering WebApp WG
Hi Doug, I'm not adamant that these requirements are met specifically just for Widgets, just that these are where the current use-cases come from. They certainly ought to be supported through more general technologies where possible. There is also the issue of abstraction; should a widget author be looking at low-level APIs to deliver functionality, or call a common high-level API which is then implemented in a device/architecture- specific way? E.g. if a widget author script wants to get the list of current participants, should it need to be rewritten for every platform it might be deployed in (e.g. XHR in some, Web Sockets in another, native code another...) or can it call widget.getParticipants() and let the UA handle the implementation? Just as, for example, the Widget Interface defines preferences using the Storage API: the actual choice of implementation of this (LocalStorage, SessionStorage, IndexedDB, WebDB, remote web service) is up to the UA. So what I'm talking about here, just to be clear, are the high level API abstractions available to a running widget (and potentially other types of web application) and not any underlying protocols used to implement them. The specific high-level APIs I'm interested in are: 1. Participants [1]: getParticipants, getViewer, getOwner, setParticipantCallback 2. State [1]: getState, state.submitDelta, state.submitValue, setStateCallback 3. Friends/People [2]: getViewerFriends, getOwnerFriends (Note these are subsets of the functionality of the referenced specifications; other functionality they specify is already covered by other W3C work such as Widgets:TWI [3] and Widgets:VMMF[4]) In some cases these APIs could map onto DAP (e.g. getViewer would map to a call on the Contacts API) but in other cases would rely on other kinds of implementations (OpenSocial itself, XHR, Websockets, Widget Feature extensions etc). The principle interoperability being addressed would be a consistent runtime model for a widget author irrespective of deployment environment. Widgets PC already has a Feature extension mechanism for handling availability of additional APIs that would be well suited to negotiating availability of these types of APIs [5]. Apache Wookie already implements Widgets PC with a subset of the Google Wave Gadget API in this fashion [6]. S [1] http://code.google.com/apis/wave/extensions/gadgets/reference.html [2] http://wiki.opensocial.org/index.php?title=OSAPI_Specification#osapi.people [3] http://www.w3.org/TR/widgets-apis/ [4] http://www.w3.org/TR/2009/WD-widgets-vmmf-20091006/ [5] http://www.w3.org/TR/widgets/#the-feature-element [6] http://incubator.apache.org/wookie/ On 12 Feb 2010, at 23:50, Doug Schepers wrote: Hi, Scott- I'm still confused as to what you're asking for as a chartered deliverable for Widgets. Like others, I am extremely reluctant to define any special functionality for Widgets, when it could be useful for Web applications at large. Let me try to break down some of what you are asking for in terms of specs we are already doing: * communication between different widgets on the same computer: Web Messaging [1] * communication between widgets on different computers: Web Sockets API [2], XHR [3] (through a gateway server) * access to contacts on a specific device: Contacts API (DAP WG) [4] * access to relationships between contacts, etc.: no current work, but possible as an online service (XHR), or locally through markup like RDFa or microdata I don't know what social APIs OpenSocial or Google Wave Gadget API expose, but anything above and beyond the deliverables listed above should probably be developed by another group (maybe in collaboration with the RDFa WG, since it probably has to do with ontologies?), and simply reused within Widgets or Web apps. But maybe I missed your point... can you give me a concise outline of what the specific use cases and requirements you have for this social API are? [1] http://dev.w3.org/html5/postmsg/ [2] http://dev.w3.org/html5/websockets/ [3] http://dev.w3.org/2006/webapi/XMLHttpRequest/ [4] http://dev.w3.org/2009/dap/contacts/ Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Scott Wilson wrote (on 2/12/10 5:39 PM): Specifically I'm thinking of access to friends/friends-of lists from author scripts in a Widget runtime. This is something of interest to widget developers, as it enables widgets to operate as social applications. OpenSocial is an obvious source of inspiration here - however the actual social APIs are only a small part of OpenSocial (which also covers all aspects of app packaging. processing. discovery and persistence) and are not easily reused in other kinds of devices and architectures. The interop problem arises as currently authors of apps/widgets are basically faced with two completely different stacks of specifications based on the presence
Re: Allow to return same NodeList object for queries like getElementsByTagName, getElementsByClassName and getElementsByName
On Fri, Jan 22, 2010 at 5:11 AM, Anton Muhin ant...@chromium.org wrote: Good day. Currently DOM core 3 spec is somewhat inconsistent regarding if invocations of getElementsByTagName and alike must return a new NodeList or could cache this list. For Document it's mandated for both getElementsByTagName and getElementsByTagNameNS, but for Element, it's only worded for getElementsByTagNameNS, but not for getElementsByTagName. Maciej noticed as well difference between getElementsByTagName and other getElementsBy queries (see http://www.w3.org/Bugs/Public/show_bug.cgi?id=8792). And word new is missing from ECMAScript bindings spec: http://www.w3.org/TR/DOM-Level-3-Core/ecma-script-binding.html Is it possible to allow caching for those cases? Firefox caches those node lists for a long time (Maciej found the related bug https://bugzilla.mozilla.org/show_bug.cgi?id=140758). IE8 caches as well. Opera, Safari and Chrome do not. I'm concerned about the GC-sensitivity of such behaviour (we might end up snookering ourselves in a situation where specific GC behaviour actually matters for compatibility). How about the following compromise: these methods return a new object each time, except if they are called with the same argument as the previous invocation of the method? i.e. cache the last returned object only. Would that be acceptable? It gives you a performance win in the case where the author spins a loop using the same call over and over, and is completely predictable. Alternatively, if we need to cache more than that, how about blowing away the cache with each spin of the event loop, so that anything in a tight loop is cached (and _not_ subject to GC — this could be a problem if the script calls one of these methods with 1 different arguments and sets properties on each one), but not beyond one task? (i.e. don't share objects in calls across setTimeout) For now for the objects in HTML5 I've gone with the first of these suggested compromises. -- Ian Hickson
Re: Allow to return same NodeList object for queries like getElementsByTagName, getElementsByClassName and getElementsByName
For me performance-wise both approaches seem fine, but to get numbers I need to run an experiment. My main concern would be that rules are overcomplicated imho. And I won't be surprised if IE and FF would just ignore them. But you understand all those matters better than I do. BTW, as the proposed change would reduce stress on GC, I don't quite see how this could reduce compatibility (but life is often more complicated than I can imagine.) yours, anton. On Sat, Feb 13, 2010 at 2:18 PM, Ian Hickson i...@hixie.ch wrote: On Fri, Jan 22, 2010 at 5:11 AM, Anton Muhin ant...@chromium.org wrote: Good day. Currently DOM core 3 spec is somewhat inconsistent regarding if invocations of getElementsByTagName and alike must return a new NodeList or could cache this list. For Document it's mandated for both getElementsByTagName and getElementsByTagNameNS, but for Element, it's only worded for getElementsByTagNameNS, but not for getElementsByTagName. Maciej noticed as well difference between getElementsByTagName and other getElementsBy queries (see http://www.w3.org/Bugs/Public/show_bug.cgi?id=8792). And word new is missing from ECMAScript bindings spec: http://www.w3.org/TR/DOM-Level-3-Core/ecma-script-binding.html Is it possible to allow caching for those cases? Firefox caches those node lists for a long time (Maciej found the related bug https://bugzilla.mozilla.org/show_bug.cgi?id=140758). IE8 caches as well. Opera, Safari and Chrome do not. I'm concerned about the GC-sensitivity of such behaviour (we might end up snookering ourselves in a situation where specific GC behaviour actually matters for compatibility). How about the following compromise: these methods return a new object each time, except if they are called with the same argument as the previous invocation of the method? i.e. cache the last returned object only. Would that be acceptable? It gives you a performance win in the case where the author spins a loop using the same call over and over, and is completely predictable. Alternatively, if we need to cache more than that, how about blowing away the cache with each spin of the event loop, so that anything in a tight loop is cached (and _not_ subject to GC — this could be a problem if the script calls one of these methods with 1 different arguments and sets properties on each one), but not beyond one task? (i.e. don't share objects in calls across setTimeout) For now for the objects in HTML5 I've gone with the first of these suggested compromises. -- Ian Hickson
Re: Allow to return same NodeList object for queries like getElementsByTagName, getElementsByClassName and getElementsByName
On 2/13/10 6:18 AM, Ian Hickson wrote: I'm concerned about the GC-sensitivity of such behaviour (we might end up snookering ourselves in a situation where specific GC behaviour actually matters for compatibility). We haven't gotten there yet, in 8 years of two different implementations having this behavior How about the following compromise: these methods return a new object each time, except if they are called with the same argument as the previous invocation of the method? i.e. cache the last returned object only. Would that be acceptable? As far as I can tell, no. That formulation makes it impossible to drop the cache as needed, effectively leading to a memory leak if no one calls these methods for a while. Alternatively, if we need to cache more than that, how about blowing away the cache with each spin of the event loop, so that anything in a tight loop is cached (and _not_ subject to GC — this could be a problem if the script calls one of these methods with 1 different arguments and sets properties on each one) Indeed. Especially because these objects can end up taking up a fair amount of memory... but not beyond one task? (i.e. don't share objects in calls across setTimeout) Those two are not quite the same condition. Implementing the latter in Gecko would not be too bad. Implementing the former, assuming I understand what you mean correctly, would require totally rewriting the Gecko event loop. -Boris
Social APIs (was: Rechartering WebApp WG)
Hi, Scott- This is certainly a valid aspect of Widgets... as a platform for a specific kind of Web application: a collaboration/discussion/sharing app. But it seems to me that this is conflating two orthogonal things: an application host environment, and a collaboration platform. Widgets can host the full range of Web apps; and a collaboration platform shouldn't be confined to Widgets. The context for a Widget, in my opinion, shouldn't inherently contain the users of that Widget; that is functionality that should be specific to collaboration apps. As an analogy, think of the Geolocation API. A recipe widget which finds recipes based on a list of available ingredients has no use for that API, but a shopping widget might; traditional web sites built to do those things would have the same needs. So, the Geolocation API is much better off as a standalone API that is available when needed, and not imposed when not needed, as general functionality, not just for Widgets. It also seems that it would require more than just an API... it needs an infrastructure from which to draw the relationship data, and security considerations. Like the Geolocation API encapsulates underlying device/service functionality (GPS, cell/wifi triangulation, logged IP locations, etc.), and the Widget Interface's Storage API uses functionality defined elsewhere (LocalStorage, SessionStorage, IndexedDB, WebDB, remote web service), a Social API would have to rely upon some source of data, which is not inherent in the device or a single established web service, so that would need to be defined. I don't think the WebApps WG is the right place to work on a Social API; I don't think it would get the specific interest such an API would require to do it right, with the current participants of this group (though others in the group should correct me if I'm wrong). Also, the WebApps WG has an urgent need to renew its charter to bring in deliverables we've already agreed are in scope, so I would be extremely reluctant to bring in a deliverable at this stage that has as broad a scope as a Social API. That's not to say a Social API is not useful or desirable. I'd love to see this done at W3C, and I think it's important to make sure it works well in both web sites and widgets. So, my counterproposal is to suggest that you work with Harry Halpin to propose a new Social API WG (maybe under Interaction Domain, but more fittingly under the Technology and Society Domain), and bring in the Google Wave and Open Social folks (since Google is already a W3C member), and find other stakeholders (Facebook?) who might also be interested, to help standardize what they have all already done. Harry and I have talked a bit before about next steps for the Social Web, and this strikes me as a logical and pragmatic next step. I will be happy to do what I can to help set this up, and to ensure good communication between our groups, and to make sure that it works well with Widgets. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Scott Wilson wrote (on 2/13/10 5:21 AM): Hi Doug, I'm not adamant that these requirements are met specifically just for Widgets, just that these are where the current use-cases come from. They certainly ought to be supported through more general technologies where possible. There is also the issue of abstraction; should a widget author be looking at low-level APIs to deliver functionality, or call a common high-level API which is then implemented in a device/architecture-specific way? E.g. if a widget author script wants to get the list of current participants, should it need to be rewritten for every platform it might be deployed in (e.g. XHR in some, Web Sockets in another, native code another...) or can it call widget.getParticipants() and let the UA handle the implementation? Just as, for example, the Widget Interface defines preferences using the Storage API: the actual choice of implementation of this (LocalStorage, SessionStorage, IndexedDB, WebDB, remote web service) is up to the UA. So what I'm talking about here, just to be clear, are the high level API abstractions available to a running widget (and potentially other types of web application) and not any underlying protocols used to implement them. The specific high-level APIs I'm interested in are: 1. Participants [1]: getParticipants, getViewer, getOwner, setParticipantCallback 2. State [1]: getState, state.submitDelta, state.submitValue, setStateCallback 3. Friends/People [2]: getViewerFriends, getOwnerFriends (Note these are subsets of the functionality of the referenced specifications; other functionality they specify is already covered by other W3C work such as Widgets:TWI [3] and Widgets:VMMF[4]) In some cases these APIs could map onto DAP (e.g. getViewer would map to a call on the Contacts API) but in other cases would rely on other kinds of implementations (OpenSocial itself, XHR, Websockets,
Re: Social APIs (was: Rechartering WebApp WG)
On 13 Feb 2010, at 20:52, Doug Schepers wrote: Hi, Scott- This is certainly a valid aspect of Widgets... as a platform for a specific kind of Web application: a collaboration/discussion/sharing app. But it seems to me that this is conflating two orthogonal things: an application host environment, and a collaboration platform. Widgets can host the full range of Web apps; and a collaboration platform shouldn't be confined to Widgets. The context for a Widget, in my opinion, shouldn't inherently contain the users of that Widget; that is functionality that should be specific to collaboration apps. As an analogy, think of the Geolocation API. A recipe widget which finds recipes based on a list of available ingredients has no use for that API, but a shopping widget might; traditional web sites built to do those things would have the same needs. So, the Geolocation API is much better off as a standalone API that is available when needed, and not imposed when not needed, as general functionality, not just for Widgets. Agreed. A Widget is only one possible consumer of such an API, so it make sense to define the API separately (with Widgets as one type of use case). It also seems that it would require more than just an API... it needs an infrastructure from which to draw the relationship data, and security considerations. Like the Geolocation API encapsulates underlying device/service functionality (GPS, cell/wifi triangulation, logged IP locations, etc.), and the Widget Interface's Storage API uses functionality defined elsewhere (LocalStorage, SessionStorage, IndexedDB, WebDB, remote web service), a Social API would have to rely upon some source of data, which is not inherent in the device or a single established web service, so that would need to be defined. Indeed, both collaborative and social apps require the container to have a means of access to a data source, and are also responsible for applying appropriate access and privacy policies; a parallel here would be DAP (and OMTP BONDI). I don't think the WebApps WG is the right place to work on a Social API; I don't think it would get the specific interest such an API would require to do it right, with the current participants of this group (though others in the group should correct me if I'm wrong). Also, the WebApps WG has an urgent need to renew its charter to bring in deliverables we've already agreed are in scope, so I would be extremely reluctant to bring in a deliverable at this stage that has as broad a scope as a Social API. That's not to say a Social API is not useful or desirable. I'd love to see this done at W3C, and I think it's important to make sure it works well in both web sites and widgets. So, my counterproposal is to suggest that you work with Harry Halpin to propose a new Social API WG (maybe under Interaction Domain, but more fittingly under the Technology and Society Domain), and bring in the Google Wave and Open Social folks (since Google is already a W3C member), and find other stakeholders (Facebook?) who might also be interested, to help standardize what they have all already done. Harry and I have talked a bit before about next steps for the Social Web, and this strikes me as a logical and pragmatic next step. I will be happy to do what I can to help set this up, and to ensure good communication between our groups, and to make sure that it works well with Widgets. I think this is a very good proposal; I'm happy to drop the proposal for doing this in Webapps and work instead with the Social Web group as you suggest. Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs Scott Wilson wrote (on 2/13/10 5:21 AM): Hi Doug, I'm not adamant that these requirements are met specifically just for Widgets, just that these are where the current use-cases come from. They certainly ought to be supported through more general technologies where possible. There is also the issue of abstraction; should a widget author be looking at low-level APIs to deliver functionality, or call a common high-level API which is then implemented in a device/architecture-specific way? E.g. if a widget author script wants to get the list of current participants, should it need to be rewritten for every platform it might be deployed in (e.g. XHR in some, Web Sockets in another, native code another...) or can it call widget.getParticipants() and let the UA handle the implementation? Just as, for example, the Widget Interface defines preferences using the Storage API: the actual choice of implementation of this (LocalStorage, SessionStorage, IndexedDB, WebDB, remote web service) is up to the UA. So what I'm talking about here, just to be clear, are the high level API abstractions available to a running widget (and potentially other types of web application) and not any underlying protocols used to implement
Re: Allow to return same NodeList object for queries like getElementsByTagName, getElementsByClassName and getElementsByName
On Feb 13, 2010, at 3:18 AM, Ian Hickson wrote: On Fri, Jan 22, 2010 at 5:11 AM, Anton Muhin ant...@chromium.org wrote: Good day. Currently DOM core 3 spec is somewhat inconsistent regarding if invocations of getElementsByTagName and alike must return a new NodeList or could cache this list. For Document it's mandated for both getElementsByTagName and getElementsByTagNameNS, but for Element, it's only worded for getElementsByTagNameNS, but not for getElementsByTagName. Maciej noticed as well difference between getElementsByTagName and other getElementsBy queries (see http://www.w3.org/Bugs/Public/show_bug.cgi?id=8792). And word new is missing from ECMAScript bindings spec: http://www.w3.org/TR/DOM-Level-3-Core/ecma-script-binding.html Is it possible to allow caching for those cases? Firefox caches those node lists for a long time (Maciej found the related bug https://bugzilla.mozilla.org/show_bug.cgi?id=140758). IE8 caches as well. Opera, Safari and Chrome do not. I'm concerned about the GC-sensitivity of such behaviour (we might end up snookering ourselves in a situation where specific GC behaviour actually matters for compatibility). It's not GC that matters but the degree of caching (e.g. whether cache items are ever cleared for reasons other than GC). It's true that this is theoretically a hazard, but the only observable effect would be whether custom properties set on one NodeList appear on one retrieved later. Since it's very uncommon (and indeed unlikely) for authors to set custom properties on NodeLists, I think this benefit is purely theoretical, not real. How about the following compromise: these methods return a new object each time, except if they are called with the same argument as the previous invocation of the method? i.e. cache the last returned object only. Would that be acceptable? It gives you a performance win in the case where the author spins a loop using the same call over and over, and is completely predictable. It's only predictable if that last object is kept alive, even if it were otherwise a candidate for garbage collection. Are you suggesting to do that? I assume so, because that's the only way it would be completely predictable. If so, then I would object, because it could lead to a large long-term memory cost (fully traversing a large NodeList in a loop would leave you paying the cost of that memory until you leave the page or the author fetches a different NodeList). Imagine the last NodeList you accessed was the result of getElementsByTagName(*) and the author fully traversed it. Now you've likely pinned memory proportional to the size of the DOM. Even without the memory issue, I would not favor this design, because it makes performance fall off a cliff if you use more than one NodeList. Changing your loop from fetching one NodeList to two could suddenly make it 50x slower. We do not like coding performance hazards like this into our implementation. Alternatively, if we need to cache more than that, how about blowing away the cache with each spin of the event loop, so that anything in a tight loop is cached (and _not_ subject to GC — this could be a problem if the script calls one of these methods with 1 different arguments and sets properties on each one), but not beyond one task? (i.e. don't share objects in calls across setTimeout) Pinning a potentially unbounded number of NodeLists in memory would definitely be unacceptable from both speed and memory perspectives. Especially on mobile devices. I note that if all you care about is ensuring that behavior is deterministic, the simplest solution would be to make NodeList objects disallow setting of custom properties. Then there is no way to observe the side effects of GC behavior. This would be simpler to implement than either of your proposed rules, and would not create speed or memory hazards. I do not know if we could justify such a change as a mere erratum to DOM Level 3 Core, but the same goes for both your proposed policies. For now for the objects in HTML5 I've gone with the first of these suggested compromises. I don't think we'd be willing to implement that in WebKit. We're more likely to copy existing Firefox and IE behavior. Regards, Maciej
Re: FormData questions
On Fri, Feb 12, 2010 at 5:32 PM, Jonas Sicking jo...@sicking.cc wrote: Hi WebApps fans! Working on implementing FormData and ran into a couple of questions. First of all, I assume that it is intended that a FromData object can be submitted several times. I.e. that the following code is ok: fd = new FormData; fd.append(name1, foo); xhr1 = new XMLHttpRequest; xhr1.open(...); xhr1.send(fd); fd.append(name2, bar); xhr2 = new XMLHttpRequest; xhr2.open(...); xhr2.send(fd); where the first XHR will send 1 name/value pair, and the second XHR will send 2. I do think this should be allowed, but I wanted to make sure others agreed. What can be a reason to disallow this? FormData is just a collection of data objects. So assuming those XHR objects are sync, the code should work as you described. Interesting question though - what happens if XHR is async and the content of FormData changes while async operation is in progress. By analogy with scenario when underlying file of Blob object changes while async reading operation is in progress, would it be reasonable to fail the send and return 'error' ProgressEvent? Second, what encoding should be used when submitting a FromData object? A few options are: * Always use UTF-8 * Allow a mimetype to be set on the FormData object, using a property or constructor argument * Use the charset mime parameter specified on the content-type header set using xhr.setRequestHeader Having a way to specify encoding could be only useful for writing client code against legacy site that takes charset-encoded form data and ignores the charset parameter of content-type header of the request. That seems rare these days. It would be way simpler to only deal with UTF-8, imo. I think the last one would be a pain for authors and for implementors. Lastly, there is a bug in the spec where it says that the mimetype should be multipart/form-data. It needs to be multipart/form-data; boundary= plus the boundary used while encoding. This also brings up the question what to do if a Content-Type header has already been set. Should a boundary mime parameter be added, or is the server side simply out of luck and won't get to know what the boundary is? / Jonas
Re: FormData questions
On Sat, Feb 13, 2010 at 6:02 PM, Dmitry Titov dim...@chromium.org wrote: On Fri, Feb 12, 2010 at 5:32 PM, Jonas Sicking jo...@sicking.cc wrote: Hi WebApps fans! Working on implementing FormData and ran into a couple of questions. First of all, I assume that it is intended that a FromData object can be submitted several times. I.e. that the following code is ok: fd = new FormData; fd.append(name1, foo); xhr1 = new XMLHttpRequest; xhr1.open(...); xhr1.send(fd); fd.append(name2, bar); xhr2 = new XMLHttpRequest; xhr2.open(...); xhr2.send(fd); where the first XHR will send 1 name/value pair, and the second XHR will send 2. I do think this should be allowed, but I wanted to make sure others agreed. What can be a reason to disallow this? FormData is just a collection of data objects. So assuming those XHR objects are sync, the code should work as you described. It complicates implementation a tiny amount, but IMHO not enough to disallow it. Interesting question though - what happens if XHR is async and the content of FormData changes while async operation is in progress. By analogy with scenario when underlying file of Blob object changes while async reading operation is in progress, would it be reasonable to fail the send and return 'error' ProgressEvent? I don't think raising an 'error' event should be correct, no. In my example above I think the two requests should succeed successfully, and the first one should submit one name/value pairs, and the second should submit two. Second, what encoding should be used when submitting a FromData object? A few options are: * Always use UTF-8 * Allow a mimetype to be set on the FormData object, using a property or constructor argument * Use the charset mime parameter specified on the content-type header set using xhr.setRequestHeader Having a way to specify encoding could be only useful for writing client code against legacy site that takes charset-encoded form data and ignores the charset parameter of content-type header of the request. That seems rare these days. It would be way simpler to only deal with UTF-8, imo. Does any browser include a charset parameter for multipart/form-data submissions? Firefox does not and last we added it it broke a bunch of sites IIRC. That was a while ago though. / Jonas
