WebTV Use Cases (was Re: [DRAFT] Web Intents Task Force Charter)
On Thu, 10 Nov 2011 17:01:51 +0100, Robin Berjon ro...@berjon.com wrote: Hi Rich, On Nov 10, 2011, at 16:27 , Rich Tibbett wrote: Opera would like to explore Local Device and Local Network Discovery as a subset of Web Intents. Yes, and that desire has been heard. As discussed last week, people interested in discovery need to bring their use cases to the intents TF so that we can figure out which just work, and for those that don't look at which of modifying intents or spawning a separate specification makes most sense. Let me add one thing on this point: if it wasn't clear from the joint F2F, the webtv IG have been discussing use cases for few months and collected them in a document that will be soon published as IG note. This document collects major use cases we are looking into. http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Requirements I'll send around the link to the final document once published, but note that NO changes are expected. /g -- Giuseppe Pascale TV Connected Devices Opera Software
Re: Discovery and Web Intents (was Re: [DRAFT] Web Intents Task Force Charter)
On Sun, 13 Nov 2011 21:34:50 +0100, Dave Raggett d...@w3.org wrote: On 12/11/11 11:42, Giuseppe Pascale wrote: * The UI web page should be able to handle devices appearing and disappearing at random times and be notified of such via events. Is this possible? I'm wondering if tḧis is actually needed. If you handle the picker natively, I think also this aspect will have to be handled by the browser and not exposed to the application. Such events are needed for context aware applications, but this is probably outside the scope of an initial web intents/local discovery API where as you suggest, the web run-time could handle this as part of the picker API and the associated background service monitoring the multicast datagrams for mDNS and SSDP, and likewise for other interconnect technologies such as USB and Bluetooth. Note also that the service not available problem is common also to could based services. I'm not sure what's the current plan for intents, but my understanding is that the issue of a service not responding is handled a communication time and not a selection time. Am I correct? Also this is probably not part of the web intent discussion. Web intents provide the general infrastructure. How do we map specific services on intent should be handled by another spec and probably discussed in DAP (or not?). We have 2 options here: have different intents for different protocols or one intent that try to cover all similar services. The first one is easier to implement, the second is much more handy for applications developers. I'm starting to think that we should try to go for the second option. If we go for that we will have to address the problem of differences in capability between different (similar) services/protocols. Agreed. We could go for a high level abstraction, but at the same time expose the protocol specific details for applications/libraries that need it. One way to do this as sub-objects for specific protocols, e.g. an UPnP object that provides access to the service descriptions UPnP defines in XML. yep. This needs more thoughts and more discussion though. Exposing more information will also bring back the security and privacy concerns someone raised. So we need to discuss if there is a way to handled features that are specific for one protocol/service preserving privacy/security as much as possible. I guess we need to give it a try and discuss around some draft/prototype. /g -- Giuseppe Pascale TV Connected Devices Opera Software
Re: [DRAFT] Web Intents Task Force Charter
On Nov 11, 2011, at 18:14 , Clarke Stevens wrote: When can we get the TF tools set up so we can move these conversations to the official forum? Given the useful conversation that we immediately jumped into, I'm considering that we have consensus to move ahead. I'm working with the W3C team to set things up ASAP. Will keep you posted as soon as I know (or the Team might announce it directly here). -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: WebTV Use Cases (was Re: [DRAFT] Web Intents Task Force Charter)
As sa note, that document is in violation of http://www.w3.org/Consortium/Translation/ The working language of the W3C is US English. The official version of a W3C document is the US English language version at the W3C site. So I fully expect it to change. On 11/14/11, Giuseppe Pascale giusep...@opera.com wrote: On Thu, 10 Nov 2011 17:01:51 +0100, Robin Berjon ro...@berjon.com wrote: Hi Rich, On Nov 10, 2011, at 16:27 , Rich Tibbett wrote: Opera would like to explore Local Device and Local Network Discovery as a subset of Web Intents. Yes, and that desire has been heard. As discussed last week, people interested in discovery need to bring their use cases to the intents TF so that we can figure out which just work, and for those that don't look at which of modifying intents or spawning a separate specification makes most sense. Let me add one thing on this point: if it wasn't clear from the joint F2F, the webtv IG have been discussing use cases for few months and collected them in a document that will be soon published as IG note. This document collects major use cases we are looking into. http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Requirements I'll send around the link to the final document once published, but note that NO changes are expected. /g -- Giuseppe Pascale TV Connected Devices Opera Software -- Sent from my mobile device
Re: WebTV Use Cases (was Re: [DRAFT] Web Intents Task Force Charter)
On Mon, 14 Nov 2011 13:30:28 +0100, timeless timel...@gmail.com wrote: As sa note, that document is in violation of http://www.w3.org/Consortium/Translation/ The working language of the W3C is US English. The official version of a W3C document is the US English language version at the W3C site. So I fully expect it to change. I mean no significant changes as in new use cases or such. I also want to point out that this is the first document of this (new in W3C) group and is a collective effort, so we apologize if it doesn't follow W3C style/pubrules. As said, we are in the process of turning it into a W3C Note document, that also imply making it compliant with pubrules. cheers, /g On 11/14/11, Giuseppe Pascale giusep...@opera.com wrote: On Thu, 10 Nov 2011 17:01:51 +0100, Robin Berjon ro...@berjon.com wrote: Hi Rich, On Nov 10, 2011, at 16:27 , Rich Tibbett wrote: Opera would like to explore Local Device and Local Network Discovery as a subset of Web Intents. Yes, and that desire has been heard. As discussed last week, people interested in discovery need to bring their use cases to the intents TF so that we can figure out which just work, and for those that don't look at which of modifying intents or spawning a separate specification makes most sense. Let me add one thing on this point: if it wasn't clear from the joint F2F, the webtv IG have been discussing use cases for few months and collected them in a document that will be soon published as IG note. This document collects major use cases we are looking into. http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Requirements I'll send around the link to the final document once published, but note that NO changes are expected. /g -- Giuseppe Pascale TV Connected Devices Opera Software -- Giuseppe Pascale TV Connected Devices Opera Software
Re: WebTV Use Cases (was Re: [DRAFT] Web Intents Task Force Charter)
What is the exact problem with this document ? Best regards JC On 14/11/11 13:56 , Giuseppe Pascale wrote: On Mon, 14 Nov 2011 13:30:28 +0100, timeless timel...@gmail.com wrote: As sa note, that document is in violation of http://www.w3.org/Consortium/Translation/ The working language of the W3C is US English. The official version of a W3C document is the US English language version at the W3C site. So I fully expect it to change. I mean no significant changes as in new use cases or such. I also want to point out that this is the first document of this (new in W3C) group and is a collective effort, so we apologize if it doesn't follow W3C style/pubrules. As said, we are in the process of turning it into a W3C Note document, that also imply making it compliant with pubrules. cheers, /g On 11/14/11, Giuseppe Pascale giusep...@opera.com wrote: On Thu, 10 Nov 2011 17:01:51 +0100, Robin Berjon ro...@berjon.com wrote: Hi Rich, On Nov 10, 2011, at 16:27 , Rich Tibbett wrote: Opera would like to explore Local Device and Local Network Discovery as a subset of Web Intents. Yes, and that desire has been heard. As discussed last week, people interested in discovery need to bring their use cases to the intents TF so that we can figure out which just work, and for those that don't look at which of modifying intents or spawning a separate specification makes most sense. Let me add one thing on this point: if it wasn't clear from the joint F2F, the webtv IG have been discussing use cases for few months and collected them in a document that will be soon published as IG note. This document collects major use cases we are looking into. http://www.w3.org/2011/webtv/wiki/HNTF/Home_Network_TF_Requirements I'll send around the link to the final document once published, but note that NO changes are expected. /g -- Giuseppe Pascale TV Connected Devices Opera Software -- JC Dufourd Directeur d'Etudes/Professor Groupe Multimedia/Multimedia Group Traitement du Signal et Images/Signal and Image Processing Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144
Re: [XHR2] overrideMimeType in state UNSENT
On Thu, 10 Nov 2011 07:53:29 +0100, Jonas Sicking jo...@sicking.cc wrote: On Wed, Nov 9, 2011 at 9:39 AM, Anne van Kesteren ann...@opera.com wrote: If we change this it makes sense to change withCredentials and timeout too I would say. Agreed. I forgot that timeout you could set at any point, because you might change your mind on it while the request is ongoing. I changed overrideMimeType and responseType to only throw at LOADING/DONE. To allow for UA optimization we do not want to allow authors to set these while the response is coming in. I changed withCredentials to only throw when not UNSENT/OPENED or if the send() flag is true. What about setRequestHeader()? This one is trickier. I would be more concerned about compatibility given that the function has been around forever and has always applied only to the current request. Additionally, since there is no API for getting the current set of request headers, it makes it hard to inspect an XHR object to ensure that it's in the correct state before reusing it. Andrew is saying Gecko does not reset the author request headers. Should we expose the author request headers? (If we should, can you start a separate thread. Maybe now is the time to improve this part of the API.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [XHR2] Disable new response types for sync XHR in Window context
On Fri, 11 Nov 2011 20:03:53 +0100, Olli Pettay olli.pet...@helsinki.fi wrote: I think we should strongly encourage web devs to move away from sync XHR (in Window context, not in Workers). It is bad for UI responsiveness. Unfortunately sync XHR has been used quite often with the old text/xml types. But maybe we could disable sync XHR for the new types, and also make .response to throw if it is used with sync XHR. Comments? I think we could make responseType throw InvalidAccessError (currently response never throws, would be nice to keep that), but we just changed responseType so you can set it before invoking open(). We could of course do that if you set responseType during UNSENT open() will throw InvalidAccessError if you set async to false. Should we do this for any features? E.g. cross-origin requests? If you pass user/password for cross-origin requests open() is already supposed to throw. http://www.w3.org/Bugs/Public/show_bug.cgi?id=14773 https://bugzilla.mozilla.org/show_bug.cgi?id=701787 https://bugs.webkit.org/show_bug.cgi?id=72154 -- Anne van Kesteren http://annevankesteren.nl/
Re: [DOM4] XML lang
On Wed, 05 Oct 2011 23:07:44 +0200, Jonas Sicking jo...@sicking.cc wrote:
As has been pointed out, you can use
Element.matchesSelector(:lang('en-us')) or XPath to test if a node
has a given language. However neither lets you actually *get* the
language of a node, just check if it matches a particular language.
Additionally, matchesSelector doesn't work on text nodes.
We already have baseURI. I suppose we could have another such thing.
lang is taken unfortunately. language? naturalLang? (Based on
img.naturalHeight/Width.)
I do not think its exact behavior should be defined in DOM4, but we can
certainly introduce the concept and say that other specifications define
it. E.g. HTML and XML.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: What type should .findAll return
On Nov 12, 2011, at 12:07 PM, Yehuda Katz wrote: Yehuda Katz (ph) 718.877.1325 On Sat, Nov 12, 2011 at 11:51 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Nov 12, 2011, at 10:27 AM, Boris Zbarsky wrote: On 11/13/11 6:10 AM, Allen Wirfs-Brock wrote: I think you're drawing a distinction between language level semantics and library routine behavior which is for practical purposes irrelevant to everyone outside the ES5 committee... It's relevant to this discussion because you have to decide what web developers actually mean when they say Array. The starting point was that you want NodeArray to be something more than just an Array. So you have do look at all aspects of Array behavior and decide which you care about. The language semantic vs library behavior is relevant because it is often much easer for engine implementers to change or extend library behavior then it is to extend language semantics. In practice, at the moment, if you want something that needs to act like an array as far as a web developer is concerned, it's [[Class]] better be Array. In the future, as you note, that might change. The most important point is that [[Class]] is neither the only nor the most important distinguishing characteristic of ECMAScript built-in Arrays. If you are just arguing about [[Class]] you are missing the point. I think it's worth noting that [[Class]] is actually used by jQuery and other implementations to identify whether an object is a real Array. It may be the case that we could revisit some of those cases, but the technique of using [[Class]] to get a less buggy picture of what an object is (compared to typeof etc.) is pretty common. We use it in SproutCore as well. The jQuery.type function: https://github.com/jquery/jquery/blob/master/src/core.js#L491-495 The class2type map: https://github.com/jquery/jquery/blob/master/src/core.js#L877-879 toString in that function is declared above as Object.prototype.toString. That said, of course other aspects of the observed behavior, such as its exposed methods, matter as well. Those functions are not using [[Class]]. They are using the standard built-in Object.prototype.toString method. Now, it so happens that the specification of toString makes use of [[Class]] but that is simply an artifact of the ES5.1 specification. It is not a language features. The technique that is used to specify toString can be changed without changing the actual behavior of the toString method. All that is really required that existing ES code that depends upon the ES5.1 toString behavior will continue to work without modification in future ES implementations that may use a different specification for toString. However, it doesn'tconstrain future code that operates upon new kinds of objects that didn't exist in the ES5.1 specification. BTW, when the ES5.1 spec. talks about objects whose [[Class]] has a specific value. it means precisely such objects as actually specified in the ES5.1 spec. [[Class]] is not an implementation extension point. In particular, ES5.1 clause 8.6.2 says: The value of the [[Class]] internal property of a host object may be any String value except one of Arguments, Array,... In other words, host object provides (such as a DOM implementation) are not allowed to define new kinds of objects whose [[Class]] is Array. It's fine to want to define a new kind of host object that is behaviorally very similar (but slight different) from instances of the built-in Array constructor. But characterizing such objects by saying they have [[Class]]==Array is a not meaningful from a ES5.1 specification perspective. Allen
Re: Indexed database API autoIncrement
On Sunday, November 13, 2011, Shawn Wilsher m...@shawnwilsher.com wrote: On 10/23/2011 3:04 PM, Jonas Sicking wrote: Good catch! This definitely needs to be specified in the spec. I have a weak preference for using 1. This has a smaller risk of triggering edge cases in the client code since it's always truthy. I.e. if someone tries to detect the presence of an id, they won't fail due to the id being 0. Looks like there was a [loose] consensus around one, but it's not specified as far as I can tell. Should I file a bug or will it get magically fixed with this e-mail? Please file bug. / Jonas
Re: [DOM4] XML lang
On Nov 14, 2011, at 16:43 , Anne van Kesteren wrote:
On Wed, 05 Oct 2011 23:07:44 +0200, Jonas Sicking jo...@sicking.cc wrote:
As has been pointed out, you can use
Element.matchesSelector(:lang('en-us')) or XPath to test if a node
has a given language. However neither lets you actually *get* the
language of a node, just check if it matches a particular language.
Additionally, matchesSelector doesn't work on text nodes.
We already have baseURI. I suppose we could have another such thing. lang
is taken unfortunately. language? naturalLang? (Based on
img.naturalHeight/Width.)
Not to bikeshed, but how about baseLang? The link with baseURI, even if
usurped, at least has a chance of sticking in memory.
I do not think its exact behavior should be defined in DOM4, but we can
certainly introduce the concept and say that other specifications define it.
E.g. HTML and XML.
+1
--
Robin Berjon - http://berjon.com/ - @robinberjon
Re: [XHR2] overrideMimeType in state UNSENT
On Mon, Nov 14, 2011 at 5:19 AM, Anne van Kesteren ann...@opera.com wrote: What about setRequestHeader()? This one is trickier. I would be more concerned about compatibility given that the function has been around forever and has always applied only to the current request. Additionally, since there is no API for getting the current set of request headers, it makes it hard to inspect an XHR object to ensure that it's in the correct state before reusing it. Andrew is saying Gecko does not reset the author request headers. Should we expose the author request headers? (If we should, can you start a separate thread. Maybe now is the time to improve this part of the API.) This isn't correct. However looking at the code, I realize that we have a bug that makes us revive old set under certain conditions, so maybe that is what he's seeing. This is a recent regression and not an intentional one. I'll file a bug to have it fixed. / Jonas
Re: Dropping XMLHttpRequest 1 (just do 2)?
I would like to point out that there could be other specifications out in the wild referencing XHR 1. This doesn't mean that you should not drop XHR 1, but would be good if the WG prepares a (short) note that gives the background around this decision and few info about the XHR 2 work, how it differs from XHR 1 and how to update references. Such a note could be sent to all (relevant) WGs/IGs and for those of us active also in groups outside W3C could be used to inform people about the change with some official text /g On Thu, 10 Nov 2011 08:44:38 +0100, Charles McCathieNevile cha...@opera.com wrote: On Wed, 09 Nov 2011 20:46:45 +0100, Karl Dubost ka...@opera.com wrote: ACTION-629 I found only 2 references found to XMLHttpRequest CR version (3 August 2010) [1] Thanks for looking around. # Resource Timing [2] Reference to XHR in the interface 4.3 The PerformanceResourceTiming Interface http://www.w3.org/TR/2011/WD-resource-timing-20110524/#type-xhr Which simply declares a constant to mean XHR without a requirement for any particular flavour. # Guidelines for Web Content Transformation Proxies 1.0 [3] 4.1.3 Treatment of Requesters that are not Web browsers Which is a note, and not under further development. [1]: http://www.w3.org/TR/2010/CR-XMLHttpRequest-20100803 [2]: http://www.w3.org/TR/2011/WD-resource-timing-20110524/ [3]: http://www.w3.org/TR/2010/NOTE-ct-guidelines-20101026/ Cheers Chaals -- Giuseppe Pascale TV Connected Devices Opera Software
Re: Dropping XMLHttpRequest 1 (just do 2)?
On Monday, November 14, 2011 at 7:05 PM, Giuseppe Pascale wrote: I would like to point out that there could be other specifications out in the wild referencing XHR 1. This doesn't mean that you should not drop XHR 1, but would be good if the WG prepares a (short) note that gives the background around this decision and few info about the XHR 2 work, how it differs from XHR 1 and how to update references. Such a note could be sent to all (relevant) WGs/IGs and for those of us active also in groups outside W3C could be used to inform people about the change with some official text Or we could avoid the whole thing and just have: http://www.w3.org/TR/XMLHttpRequest/ redirect to: http://www.w3.org/TR/XMLHttpRequest2/ Better yet, dump the 2 version number and just have /XMLHttpRequest2/ point to /XMLHttpRequest/. Everything in 1 is in 2, so making a big deal out of this is a valuable waste of time justifying the decision. There is no point in having Level 1 and Level 2 since there is no Level 1… there is just XMLHttpRequest :)
Re: Dropping XMLHttpRequest 1 (just do 2)?
On Mon, 14 Nov 2011 19:19:37 +0100, Marcos Caceres w...@marcosc.com wrote: Better yet, dump the 2 version number and just have /XMLHttpRequest2/ point to /XMLHttpRequest/. Everything in 1 is in 2, so making a big deal out of this is a valuable waste of time justifying the decision. There is no point in having Level 1 and Level 2 since there is no Level 1… there is just XMLHttpRequest :) I favor this approach. -- Anne van Kesteren http://annevankesteren.nl/
Re: Dropping XMLHttpRequest 1 (just do 2)?
On Mon, 14 Nov 2011 19:31:55 +0100, Anne van Kesteren ann...@opera.com wrote: On Mon, 14 Nov 2011 19:19:37 +0100, Marcos Caceres w...@marcosc.com wrote: Better yet, dump the 2 version number and just have /XMLHttpRequest2/ point to /XMLHttpRequest/. Everything in 1 is in 2, so making a big deal out of this is a valuable waste of time justifying the decision. There is no point in having Level 1 and Level 2 since there is no Level 1… there is just XMLHttpRequest :) I favor this approach. If that's the case would be possible to replace xhr 1 spec text with xhr 2 text spec and drop 2? Any issue in doing that? -- Giuseppe Pascale TV Connected Devices Opera Software
Re: What type should .findAll return
[snip] ES5.1 clause 8.6.2 says: The value of the [[Class]] internal property of a host object may be any String value except one of Arguments, Array,... In other words, host object provides (such as a DOM implementation) are not allowed to define new kinds of objects whose [[Class]] is Array. It's fine to want to define a new kind of host object that is behaviorally very similar (but slight different) from instances of the built-in Array constructor. But characterizing such objects by saying they have [[Class]]==Array is a not meaningful from a ES5.1 specification perspective. I'm fine with any formulation, as long as it gives the correct behaviour in cases like Array.prototype.concat and Array.isArray. ES 5.1 15.4.3.2 Array.isArray() ... 2. If the value of the [[Class]] internal property of arg is Array, then return true. ... Considering Allen's previous comment, this is not going to be allowed. Rick Do you have suggestions for what to write? / Jonas
Re: Last Call Comments on Web Storage
Hi Ashok, I agree with Tab's comments and wanted to mention some of the related history ... The relationships between WebApps' various database related specs has been discussed before and [DB-wiki] was created to help clarify the relationships. The good news is there are now 2 specs rather than 4 but the wiki is a bit outdated so I recorded [Action-640] as a reminder to update it during Web Storage's CR period and inputs/updates from others is welcome. Additionally, because of some concerns about what I would call shortcomings of Web Storage when compared with IDB, last June we held a poll [RfC-Storage] to determine if there was consensus to continue work on that spec or to stop work on it (and to publish it as a WG Note). The consensus was to continue to move the spec to REC. -Art Barstow [DB-wiki] http://www.w3.org/2008/webapps/wiki/Database [RfC-Storage] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1110.html [Action-640] http://www.w3.org/2008/webapps/track/actions/640 On 11/11/11 3:24 PM, ext Tab Atkins Jr. wrote: On Fri, Nov 11, 2011 at 11:54 AM, ashok malhotra ashok.malho...@oracle.com wrote: o One use of local storage might be to store personal preferences, such as travel preferences or personal information such as medical history. In such cases, you may want to allow several sites access to this information (I prefer aisle seats; I would like to stay at Marriott hotels.) Local storage is governed by the same-origin policy but in some cases it may be wise to carefully relax this and allow multiple sites to access the data. It seems that these are *not* the sort of thing you want to leave to ad-hoc data storage. Instead, this should be approached from a standardization perspective. o When updating local storage, transactional semantics or, at least, a transactional option would be desirable. IndexedDB is intended to be the better version of localStorage, and utilizes transactional semantics. o It would be very useful to be able to map from other forms of data storage, such as RDF or Relational data to RDF. Mapping from RDF would be simple. Mapping from Relational is more challenging. What's the use-case for taking in RDF and storing it in localStorage? One can always just store RDF directly as a localStorage *value*. o If local storage is used to store personal preferences or personal information it would be very useful to be able to move it from one device to another, say my laptop to my phone. This is left to either the app or the browser to achieve. o Question: The values in the key-value pairs are typed as strings but I presume they can be URIs and be interpreted as URIs. Or they can be large files. Perhaps this could be clarified. They are always strings, but of course they can represent any type of data that can be stringified and revived. The application can choose to interpret them as urls or files if it wishes. However, storing large files is better done through the FileSystem API or through IndexedDB. ~TJ
Re: Last Call Comments on Web Storage
I don't think it's controversial amongst practitioners that both Web Storage and IndexedDB are useful and should exist. WebStorage is a very simple key-value store that is useful for very common, simple cases, while IndexedDB is a full-on database solution more appropriate for complex cases. One thing that came up during the Offline Workshop was that Web Storage is often used as a kludge to get around limitations in the browser's native ability to expose resource caching to JavaScript (either via application cache or via a new API). With that said, Web Storage would still be extremely useful for simple user data that did not require the full programming model of a database. Yehuda Katz (ph) 718.877.1325 On Mon, Nov 14, 2011 at 2:44 PM, Arthur Barstow art.bars...@nokia.comwrote: Hi Ashok, I agree with Tab's comments and wanted to mention some of the related history ... The relationships between WebApps' various database related specs has been discussed before and [DB-wiki] was created to help clarify the relationships. The good news is there are now 2 specs rather than 4 but the wiki is a bit outdated so I recorded [Action-640] as a reminder to update it during Web Storage's CR period and inputs/updates from others is welcome. Additionally, because of some concerns about what I would call shortcomings of Web Storage when compared with IDB, last June we held a poll [RfC-Storage] to determine if there was consensus to continue work on that spec or to stop work on it (and to publish it as a WG Note). The consensus was to continue to move the spec to REC. -Art Barstow [DB-wiki] http://www.w3.org/2008/**webapps/wiki/Databasehttp://www.w3.org/2008/webapps/wiki/Database [RfC-Storage] http://lists.w3.org/Archives/**Public/public-webapps/** 2011AprJun/1110.htmlhttp://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1110.html [Action-640] http://www.w3.org/2008/**webapps/track/actions/640http://www.w3.org/2008/webapps/track/actions/640 On 11/11/11 3:24 PM, ext Tab Atkins Jr. wrote: On Fri, Nov 11, 2011 at 11:54 AM, ashok malhotra ashok.malho...@oracle.com wrote: o One use of local storage might be to store personal preferences, such as travel preferences or personal information such as medical history. In such cases, you may want to allow several sites access to this information (I prefer aisle seats; I would like to stay at Marriott hotels.) Local storage is governed by the same-origin policy but in some cases it may be wise to carefully relax this and allow multiple sites to access the data. It seems that these are *not* the sort of thing you want to leave to ad-hoc data storage. Instead, this should be approached from a standardization perspective. o When updating local storage, transactional semantics or, at least, a transactional option would be desirable. IndexedDB is intended to be the better version of localStorage, and utilizes transactional semantics. o It would be very useful to be able to map from other forms of data storage, such as RDF or Relational data to RDF. Mapping from RDF would be simple. Mapping from Relational is more challenging. What's the use-case for taking in RDF and storing it in localStorage? One can always just store RDF directly as a localStorage *value*. o If local storage is used to store personal preferences or personal information it would be very useful to be able to move it from one device to another, say my laptop to my phone. This is left to either the app or the browser to achieve. o Question: The values in the key-value pairs are typed as strings but I presume they can be URIs and be interpreted as URIs. Or they can be large files. Perhaps this could be clarified. They are always strings, but of course they can represent any type of data that can be stringified and revived. The application can choose to interpret them as urls or files if it wishes. However, storing large files is better done through the FileSystem API or through IndexedDB. ~TJ
Re: What type should .findAll return
It seems as though the spec intends to disallow host objects (i.e. DOM) from fully acting like an Array, which is clearly the intent here. Perhaps this is a time for willful disobedience and a correction in ES6? Yehuda Katz (ph) 718.877.1325 On Mon, Nov 14, 2011 at 10:46 AM, Rick Waldron waldron.r...@gmail.comwrote: [snip] ES5.1 clause 8.6.2 says: The value of the [[Class]] internal property of a host object may be any String value except one of Arguments, Array,... In other words, host object provides (such as a DOM implementation) are not allowed to define new kinds of objects whose [[Class]] is Array. It's fine to want to define a new kind of host object that is behaviorally very similar (but slight different) from instances of the built-in Array constructor. But characterizing such objects by saying they have [[Class]]==Array is a not meaningful from a ES5.1 specification perspective. I'm fine with any formulation, as long as it gives the correct behaviour in cases like Array.prototype.concat and Array.isArray. ES 5.1 15.4.3.2 Array.isArray() ... 2. If the value of the [[Class]] internal property of arg is Array, then return true. ... Considering Allen's previous comment, this is not going to be allowed. Rick Do you have suggestions for what to write? / Jonas
Re: What type should .findAll return
On Nov 14, 2011, at 3:13 PM, Yehuda Katz wrote: It seems as though the spec intends to disallow host objects (i.e. DOM) from fully acting like an Array, which is clearly the intent here. Perhaps this is a time for willful disobedience and a correction in ES6? Calm down -- this confrontational style is unjustified. The spec cannot deal in non-observables. DOM host objects in most implementations are full of methods, which really are native function objects. But it's always possible to implement a work-alike. So long as a host array follows the contract in every observable way, no problem. What's at issue is the abuse of internal methods defined only for spec-internal purposes as arbitrary plugin APIs by other specs. That's where negotiation and future-proofing are needed. /be Yehuda Katz (ph) 718.877.1325 On Mon, Nov 14, 2011 at 10:46 AM, Rick Waldron waldron.r...@gmail.com wrote: [snip] ES5.1 clause 8.6.2 says: The value of the [[Class]] internal property of a host object may be any String value except one of Arguments, Array,... In other words, host object provides (such as a DOM implementation) are not allowed to define new kinds of objects whose [[Class]] is Array. It's fine to want to define a new kind of host object that is behaviorally very similar (but slight different) from instances of the built-in Array constructor. But characterizing such objects by saying they have [[Class]]==Array is a not meaningful from a ES5.1 specification perspective. I'm fine with any formulation, as long as it gives the correct behaviour in cases like Array.prototype.concat and Array.isArray. ES 5.1 15.4.3.2 Array.isArray() ... 2. If the value of the [[Class]] internal property of arg is Array, then return true. ... Considering Allen's previous comment, this is not going to be allowed. Rick Do you have suggestions for what to write? / Jonas
Re: What type should .findAll return
Sorry, I was making a joke (referencing 1.5.2 of the HTML5 spec), not intending to be confrontational. The underlying issue here is just making it possible for Array.isArray to return true for an Array of DOM nodes that is also enhanced with extra features. Jonas had specifically said that he wanted isArray to work. Rick then pointed out that the spec seems to disallow host objects from claiming that their [[Class]] is Array, and that isArray specifically requires that [[Class]] be Array. I apologize again for my in-jest comment. Yehuda Katz (ph) 718.877.1325 On Mon, Nov 14, 2011 at 3:23 PM, Brendan Eich bren...@mozilla.org wrote: On Nov 14, 2011, at 3:13 PM, Yehuda Katz wrote: It seems as though the spec intends to disallow host objects (i.e. DOM) from fully acting like an Array, which is clearly the intent here. Perhaps this is a time for willful disobedience and a correction in ES6? Calm down -- this confrontational style is unjustified. The spec cannot deal in non-observables. DOM host objects in most implementations are full of methods, which really are native function objects. But it's always possible to implement a work-alike. So long as a host array follows the contract in every observable way, no problem. What's at issue is the abuse of internal methods defined only for spec-internal purposes as arbitrary plugin APIs by other specs. That's where negotiation and future-proofing are needed. /be Yehuda Katz (ph) 718.877.1325 On Mon, Nov 14, 2011 at 10:46 AM, Rick Waldron waldron.r...@gmail.comwrote: [snip] ES5.1 clause 8.6.2 says: The value of the [[Class]] internal property of a host object may be any String value except one of Arguments, Array,... In other words, host object provides (such as a DOM implementation) are not allowed to define new kinds of objects whose [[Class]] is Array. It's fine to want to define a new kind of host object that is behaviorally very similar (but slight different) from instances of the built-in Array constructor. But characterizing such objects by saying they have [[Class]]==Array is a not meaningful from a ES5.1 specification perspective. I'm fine with any formulation, as long as it gives the correct behaviour in cases like Array.prototype.concat and Array.isArray. ES 5.1 15.4.3.2 Array.isArray() ... 2. If the value of the [[Class]] internal property of arg is Array, then return true. ... Considering Allen's previous comment, this is not going to be allowed. Rick Do you have suggestions for what to write? / Jonas
Re: What type should .findAll return
On Nov 14, 2011, at 3:32 PM, Yehuda Katz wrote: Sorry, I was making a joke (referencing 1.5.2 of the HTML5 spec), not intending to be confrontational. Ah, I get it -- indeed such deviations were one of the reasons for creating public-script-coord. SO I get it but I didn't lul. :-| The underlying issue here is just making it possible for Array.isArray to return true for an Array of DOM nodes that is also enhanced with extra features. Jonas had specifically said that he wanted isArray to work. Rick then pointed out that the spec seems to disallow host objects from claiming that their [[Class]] is Array, and that isArray specifically requires that [[Class]] be Array. We need to get this right in the future. It's a tricky issue. But even now I would say that if there's no observable difference, there is no problem. Allen should weigh in. /be I apologize again for my in-jest comment. Yehuda Katz (ph) 718.877.1325 On Mon, Nov 14, 2011 at 3:23 PM, Brendan Eich bren...@mozilla.org wrote: On Nov 14, 2011, at 3:13 PM, Yehuda Katz wrote: It seems as though the spec intends to disallow host objects (i.e. DOM) from fully acting like an Array, which is clearly the intent here. Perhaps this is a time for willful disobedience and a correction in ES6? Calm down -- this confrontational style is unjustified. The spec cannot deal in non-observables. DOM host objects in most implementations are full of methods, which really are native function objects. But it's always possible to implement a work-alike. So long as a host array follows the contract in every observable way, no problem. What's at issue is the abuse of internal methods defined only for spec-internal purposes as arbitrary plugin APIs by other specs. That's where negotiation and future-proofing are needed. /be Yehuda Katz (ph) 718.877.1325 On Mon, Nov 14, 2011 at 10:46 AM, Rick Waldron waldron.r...@gmail.com wrote: [snip] ES5.1 clause 8.6.2 says: The value of the [[Class]] internal property of a host object may be any String value except one of Arguments, Array,... In other words, host object provides (such as a DOM implementation) are not allowed to define new kinds of objects whose [[Class]] is Array. It's fine to want to define a new kind of host object that is behaviorally very similar (but slight different) from instances of the built-in Array constructor. But characterizing such objects by saying they have [[Class]]==Array is a not meaningful from a ES5.1 specification perspective. I'm fine with any formulation, as long as it gives the correct behaviour in cases like Array.prototype.concat and Array.isArray. ES 5.1 15.4.3.2 Array.isArray() ... 2. If the value of the [[Class]] internal property of arg is Array, then return true. ... Considering Allen's previous comment, this is not going to be allowed. Rick Do you have suggestions for what to write? / Jonas
Re: What type should .findAll return
Yehuda Katz (ph) 718.877.1325 On Mon, Nov 14, 2011 at 3:49 PM, Brendan Eich bren...@mozilla.org wrote: On Nov 14, 2011, at 3:32 PM, Yehuda Katz wrote: Sorry, I was making a joke (referencing 1.5.2 of the HTML5 spec), not intending to be confrontational. Ah, I get it -- indeed such deviations were one of the reasons for creating public-script-coord. SO I get it but I didn't lul. :-| The underlying issue here is just making it possible for Array.isArray to return true for an Array of DOM nodes that is also enhanced with extra features. Jonas had specifically said that he wanted isArray to work. Rick then pointed out that the spec seems to disallow host objects from claiming that their [[Class]] is Array, and that isArray specifically requires that [[Class]] be Array. We need to get this right in the future. It's a tricky issue. But even now I would say that if there's no observable difference, there is no problem. Allen should weigh in. One observable difference between this object and an Array (at least under Jonas' proposal) would be that: Object.getPrototypeOf(Object.getPrototypeOf(arrayOfNodes)) would be the inserted DOM list prototype, while Object.getPrototypeOf(Object.getPrototypeOf(regularArray)) would be Object.prototype It would be possible to mask this behavior, but masking it and also making it possible to extend the DOM list prototype would be weird, no? /be I apologize again for my in-jest comment. Yehuda Katz (ph) 718.877.1325 On Mon, Nov 14, 2011 at 3:23 PM, Brendan Eich bren...@mozilla.org wrote: On Nov 14, 2011, at 3:13 PM, Yehuda Katz wrote: It seems as though the spec intends to disallow host objects (i.e. DOM) from fully acting like an Array, which is clearly the intent here. Perhaps this is a time for willful disobedience and a correction in ES6? Calm down -- this confrontational style is unjustified. The spec cannot deal in non-observables. DOM host objects in most implementations are full of methods, which really are native function objects. But it's always possible to implement a work-alike. So long as a host array follows the contract in every observable way, no problem. What's at issue is the abuse of internal methods defined only for spec-internal purposes as arbitrary plugin APIs by other specs. That's where negotiation and future-proofing are needed. /be Yehuda Katz (ph) 718.877.1325 On Mon, Nov 14, 2011 at 10:46 AM, Rick Waldron waldron.r...@gmail.comwrote: [snip] ES5.1 clause 8.6.2 says: The value of the [[Class]] internal property of a host object may be any String value except one of Arguments, Array,... In other words, host object provides (such as a DOM implementation) are not allowed to define new kinds of objects whose [[Class]] is Array. It's fine to want to define a new kind of host object that is behaviorally very similar (but slight different) from instances of the built-in Array constructor. But characterizing such objects by saying they have [[Class]]==Array is a not meaningful from a ES5.1 specification perspective. I'm fine with any formulation, as long as it gives the correct behaviour in cases like Array.prototype.concat and Array.isArray. ES 5.1 15.4.3.2 Array.isArray() ... 2. If the value of the [[Class]] internal property of arg is Array, then return true. ... Considering Allen's previous comment, this is not going to be allowed. Rick Do you have suggestions for what to write? / Jonas
[Bug 14830] New: Specify where index values are gotten from
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14830 Summary: Specify where index values are gotten from Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API AssignedTo: dave.n...@w3.org ReportedBy: jo...@sicking.cc QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specifically, are they retrieved from the object passed to .add/.put/.update, or from the structured clone of that value. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [indexeddb] Keypath attribute lookup question
On Sat, Nov 12, 2011 at 2:14 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Nov 11, 2011 at 5:07 PM, Israel Hilerio isra...@microsoft.com wrote: On Wednesday, November 09, 2011 4:47 PM, Joshua Bell wrote: On Wed, Nov 9, 2011 at 3:35 PM, Israel Hilerio isra...@microsoft.com wrote: In section 4.7 Steps for extracting a key from a value using a key path step #4 it states that: * If object does not have an attribute named attribute, then skip the rest of these steps and no value is returned. We want to verify that the attribute lookup is taking place on the immediate object attributes and the prototype chain, correct? My reading of the spec: In 3.2.5 the description of add (etc) says that the method creates a structured clone of value then runs the store operation with that cloned value. The steps for storing a record (5.1) are the context where the key path is evaluated, which would imply that it is done against the cloned value. The structured cloning algorithm doesn't walk the prototype chain, so this reading would indicate that the attribute lookup only occurs against the immediate object. I believe there's a spec issue in that in section 3.2.5 the list of cases where DataError is thrown are described without reference to the value parameter (it's implied, but not stated), followed by Otherwise this method creates a structured clone of the value parameter. That implies that these error cases apply to the value, whereas the storage operations apply to the structured clone of the value. (TOCTOU?) We (Chrome) believe that the structured clone step should occur prior to the checks and the cloned value be used for these operations. What you're saying makes sense! The scenario we are worried about is the one in which we want to be able to index on the size, type, name, and lastModifiedDate attributes of a File object. Given the current SCA serialization logic, I'm not sure this is directly supported. This could become an interoperable problem if we allow these properties to be serialized and indexed in our implementation but FF or Chrome don't. We consider Blobs and Files to be host objects and we treat those a little different from regular JavaScript Objects. We feel that the ability to index these properties enables many useful scenarios and would like to see all browsers support it. What do you and Jonas think? Wow, good points all around. My concern about getting properties off of the structured clone is one of performance. Currently when we do a structured clone we actually simply serialize the object graph. Serializing needs to happen anyway so we might as well do it as part of structured cloning. Turns out this is the case in basically *all* APIs which use structured clones, that they need to both clone and serialize, so this has worked great as an implementation strategy, both for code reuse and performance reasons. So my concern is that if we get the properties off of the structured clone, then it means getting them not from an object graph, but from a serialized thing. I also concur with Israel's comment. Though this seems solvable by simply adding more smarts to the code which reads the values from the serialized thing as to make it support native objects. We have the exact same issue as microsoft here. On the flip side, I definitely see a risk if we get the index values from the object prior to structured clone. This could prevent optimizations such as being able to read out the index values on the database thread. This could be useful when deleting an item from the objectStore so that the relevant values from all indexes can be removed. I'll have to confer with other people at mozilla before expressing a too strong opinion either way here. I talked this over with people that knows our structured clone implementation better than me. As I see it, the main question is if we should do the index-value lookup on the value handed to the .put/.add/.update function, or if we should do the lookup on the structured clone of that value. I.e. if someone calls objectStore.add(X); we will before the .add function returns, create a structured clone of the value in X. The question is if we should look up index values on X, or on the structured clone of X. There are several behavioral differences between the two. For example if any values on X are implemented using getters, then those getters might return different things when the structured clone is happening, and when the index-value-getting code is executing. Another difference is that for any non-host object, any values that live on the prototype chain get lost during the structured clone since it doesn't copy the prototype chain. What I think we should do is to get index values from the structured clone of X. There at least two advantages of this: 1. The code to get index values can run on the database thread of the IDB implementation. This enables a more parallel implementation.
Re: innerHTML in DocumentFragment
On Fri, Nov 11, 2011 at 3:42 AM, Henri Sivonen hsivo...@iki.fi wrote: On Thu, Nov 10, 2011 at 7:32 PM, Jonas Sicking jo...@sicking.cc wrote: I don't think we should make up rules for where it makes sense to insert DOM and where it doesn't. After all, we support .innerHTML on all HTML elements (and soon maybe all Elements), and not just a subset of them, right? Yes, but with innerHTML on elements, we always have a context node, so there isn't magic DWIM involved. But you don't need to look far to find special cases with difficult elements: We also support createContextualFragment with all possible contexts except we special-case things so that if the context is html in the (X)HTML namespace, the behavior is as if the context had been body in the (X)HTML namespace. On reasonable view is that solutions should always be complete and make sense (for some notion of making sense) for all inputs. Another reasonable view is that we shouldn't do anything with for compleness as the rationale and that everything that needs notable additional engineering needs to be justified by use cases. If no one really wants to use DWIM parsing to create a DocumentFragment that has the html element in the (X)HTML namespace as its child, why put the engineering effort into supporting such a case? Currently, per spec (and Ragnarök, Chrome and Firefox comply and interoperate), if you take take an HTML document that has head and body (as normal) and assign document.body.outerHTML = document.body.outerHTML, you get an extra head so that the document has 2 heads. Would you expend engineering effort, for the sake of making sense in all cases for completeness, to get rid of the extra head even though there are likely no use cases and 3 out of 4 engines interoperate while complying with the spec? And requiring that a context node is passed in in all cases when HTML is parsed is terrible developer ergonomics. One possibility is that instead of adding innerHTML to DocumentFragment, we add three methods to Document: DocumentFragment parseFragment(DOMString htmlMarkup); DocumentFragment parseSvgFragment(DOMString svgMarkup); DocumentFragment parseMathFragment(DOMString mathmlMarkup); parseFragment would do roughly the kind of DWIM Yehuda suggested. That is, you'd get to use tr with it but not html. parseSvgFragment would invoke the HTML fragment parsing algorithm with svg in the SVG namespace as the context. parseMathFragment would invoke the HTML fragment parsing algorithm with math in the MathML namespace as the context. That fails the main requirement in the initial email. Being able to implement a function that doesn't require context but still can parse markup to be inserted into the page. We have also identified one possible future API where this will be needed: When/if we add support for a html-parsing ES.next quasi-literal. Another use case that I realized earlier today is the need for the same thing when parsing the contents of a template element. The functionality here is the important thing, the exact syntax is something we can debate separately. As a bonus, developers would need to call createDocumentFragement() first. This is a goal that we can easily archive no matter what. frag.innerHTML = g/g; someSVGElement.appendChild(frag); seems very possible to make work Making it work is a problem with a. I think we should have three DocumentFragment-returning parsing methods instead of packing a lot of magic into innerHTML on DocumentFragment, when having to obtain a DocumentFragment first and filling it as a separate step sucks as far as developer ergonomics go. This just moves the complexity from UA authors to library authors and web authors. I don't think that is a win. someTableElement.innerHTML = tr.../trdiv/div; will just drop the div on the floor. By what mechanism? (It didn't implement and run Yehuda's suggestion, but I'm pretty sure it wouldn't drop the div. Why would we put additional effort into dropping the div?) I'm saying that this is what we do today. Note that my example doesn't set innerHTML on a DocumentFragment, but on a table element. However trying this out in Gecko it appears that we simply insert the div as a direct child of the table element. So I retract this point as it is moot. / Jonas
Re: What type should .findAll return
On Nov 14, 2011, at 3:32 PM, Yehuda Katz wrote: Sorry, I was making a joke (referencing 1.5.2 of the HTML5 spec), not intending to be confrontational. The underlying issue here is just making it possible for Array.isArray to return true for an Array of DOM nodes that is also enhanced with extra features. Jonas had specifically said that he wanted isArray to work. Rick then pointed out that the spec seems to disallow host objects from claiming that their [[Class]] is Array, and that isArray specifically requires that [[Class]] be Array. Ultimate you have to decide what it is you are asking for. It been stated that you (DOM API designers) want this kind of object to be a real ECMAScript Array. But you also want to deviate from some aspects of what it currently means to be an a real ECMAScript array. A real ECMAscript Array has a specific [[Prototype]] value. It also has specific behaviors for methods like concat and filter and other specific distinguishing behavioral characteristics all of which are defined in the ES5.1 spec. If you change any of those for some object, it is something other than a real ECMAScript Array. Array.isArray was introduced into ES5 to provide an API for testing whether or not an object actually was a real ECMAScript Array as defined by section 15.4 of the ES5 spec. If Array.isArray starts answering true for objects that aren't described by 15.4 then it ls no longer useful for its intended purpose. The language in 8.6.2 limiting host object use of certain class values is to ensure that host objects can't define things that violate important invariant about the inner workings of ECMAScript. Nobody is saying that it isn't useful to define new objects (host or otherwise) that share some (but not all) of the characteristics of ECMAScript Arrays. However, such object's aren't just ECMAScript array as defined by 15.4 so don't expect Array.isArray to work for them. Perhaps other discriminators are needed but we will all need to decide which specific subset of Array characteristics we want to discriminate. TC39 recognizes that ES needs better support for defining collections, including variants of Array. This includes supporting both better collections defined in ES code and via host objects (in general, TC39 don't like designs that depend uopn a host object being able to do something that can't be done only using ES code). We have features to support better collection definition in advanced stages of design for ES6. Some of these features might be accelerated into implementation ahead of the completion of ES6. However, I'm not sure you would want to normatively specify a DOM feature that depended upon them. Maybe you could... For right now, there are two ways you could quickly go that don't conflict with ES5.1 at all: 1) you can specify that .findAll returns a plain vanilla ECMAScript Array object. 2) you can define a new kind of host object that is a close approximation of a real ECMAScript Array object. Such an object could indirectly inherit from Array.prototype, over-ride some inherited methods (such as concat and filter), and define additional DOM related methods. However, its [[Class]] may not be Array and anything in the ES spec that requires [[Class]]===Array (such as Array.isArray) won't recognize it as an anything special. We can work together on something between these two extremes but the further away from them we go the more we get into the land of ES6 features and the problem of how to advance them into current engines. Allen
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
On 11/13/11 3:18 PM, Paul Kinlan wrote: On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: On 11/10/11 3:10 PM, Greg Billock wrote: On Thu, Nov 10, 2011 at 8:15 AM, Rich Tibbett ri...@opera.com mailto:ri...@opera.com wrote: Dominique Hazael-Massieux wrote: Le jeudi 10 novembre 2011 à 16:27 +0100, Rich Tibbett a écrit : Hi a.) to register a URL endpoint as an intent provider the user must visit a web page (presumably hosted by the target device itself) and capture the intent registration from that page before that intent provider can be used within the UA. My understanding is that this is not a MUST at all, but the way Web-based services can be added by a user. Yes. The API as currently proposed has a way for web apps to register services, but it is not intended to limit the ability of the user agent to register services by other methods. If you look at our Chromium commits, we're experimenting with ways to register services through installation of web apps, for instance. Registering handlers through local network discovery or interaction with the host OS also seems like a promising direction. Has there been further movement toward the existing register*Handler APIs: http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#custom-handlers I've practiced with those methods and from a usability perspective, I'm starting to think those html5 methods are not going to be worth using. Whatever the end-case, Web Intents seems to be where the UI is going to evolve. I understand that from the Chromium-OS side, Web Intents is likely to take over the fileHandlers permission. That tells me that registerContentHandler is not going to happen. The intent model can support view with the associated MIME-type which is what regsiterContentHandler does. The point we need to discuss is registerContentHandler will implicitly start when a file is loaded with that mime-type, so should a UA initiate startActivity implicitly with a view, the detected mime type and the file data? Seems like the UA gets to make all of the decisions here. I think the disposition=inline vs. [a download] really sets up the intent well. If the anchor is marked for inline, it makes a lot of sense that the UA would check on its registered intents for handling it implicitly. There's no reason to push authors into triggering intents when the user can setup those preferences on their own. PDF is a good model for this one... it's a view situation and it's likely to have only one viewer, and it's also likely to be viewed inline. Mozilla's work on PDF.js is certainly showing the power of web app registration for this complex file format. I know if I register pdf.js as my PDF viewer, that's what I want to pop up. I also know that, if I'm running Chrome, I want, somewhere, the option of switching between the Foxit and Mozilla viewers. I'm not really happy with the Chrome interface for adding and removing registered protocol handlers. It's so buried, nobody is going to know about it. Web Intents really fills that gap of Open With... and context menus. I find the existing context-menu solution distasteful: a background page just so I can register a link? ugh!#$. Does anybody use registerProtocolHandler in any real sense? Is registerContentHandler needed? It seems like Web Intents is an evolution on the concept. I don't think we're going to see convergence on those old methods. I'm ready to leave them both in favor of a yet-to-be announced candidate (web intents). URIs are better than protocols, and Intents are better than content handlers. In my opinion. Thanks for the quick reply and good to ensure this stuff gets captured in the TF charter. As Chaals said, let's get going on this. The concept of Web Intents is great and we're not married to any particular proposal at this point. We can see if it works for our UCs when the task force kicks off. Clarke Stevens asked about a discovery mechanism whereby a client page discovers a set of local network devices which is then updated by an event driven mechanism. As currently sketched out, there's room in our web intents proposal for the return of a MessagePort for persistent communication. The proposal doesn't focus on that problem, though. It is aimed more at an RPC-style request/response interaction paradigm. Web Intents, the way we're currently thinking about it, has a lot to do with user consent to the connection between the applications. When there's a persistent connection, that consent model starts to break down. That
Re: Web Messaging Intents, was: Re: [DRAFT] Web Intents Task Force Charter
So, to make things difficult again -- how do we monitor progress? When I'm saving to the cloud, I want my XHR onprogress. I don't need high-fidelity progress events -- they don't even make sense when one server is copying to another, but I do need something, otherwise we're back in the dark ages of polling on a separate channel. This is an area where a MessageChannel could be handy; even an EventSource would work out, though it feels a little awkward. It's only one way, which is all that's needed, so maybe it's the right place to be looking. http://dev.w3.org/html5/eventsource/ -Charles On 11/13/11 3:24 PM, Paul Kinlan wrote: On the subject of FileSaver, specifically window.saveAs, I have demos that show use of http://webintents.org/save; intent which fits work very well and it would be up to the UA to decide if they want to offer an interface for access to the local fileSystem. So it could either be a cloud or local FS that the user chooses. On Sun, Nov 13, 2011 at 10:35 PM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: On 11/10/11 3:10 PM, Greg Billock wrote: I think the Web-page-in-a-separate tab is also an optional aspect of Web intents; the browser could serve as a broker between the local-network service and the Web page. This is unclear but I hope we end up with something that provides non-tabbed (direct) interaction also. In some cases it may be superfluous to have a separate window open that denotes the service endpoint. The proposal we're working from uses disposition=inline to denote this -- that is, services can be placed within the visual context of the calling page. Our prototype uses an expansion of the service picker dialog to host that service page. It seems like the anchor download attribute fills another need. Should these proposals be wrapped up into an omnibus package? In my opinion, they're an extension to the very-old target attribute. In the new Web Apps world, we're targeting FileSaver and iframe sandbox.
RE: What type should .findAll return
From: Allen Wirfs-Brock [mailto:al...@wirfs-brock.com] Sent: Monday, November 14, 2011 6:12 PM For right now, there are two ways you could quickly go that don't conflict with ES5.1 at all: 1) you can specify that .findAll returns a plain vanilla ECMAScript Array object. 2) you can define a new kind of host object that is a close approximation of a real ECMAScript Array object. Such an object could indirectly inherit from Array.prototype, over-ride some inherited methods (such as concat and filter), and define additional DOM related methods. However, its [[Class]] may not be Array and anything in the ES spec that requires [[Class]]===Array (such as Array.isArray) won't recognize it as an anything special. This might be my simplified view of things, but have we just circled back around to the two definitions that Cameron already has in WebIDL [1]? * 3.9.18 Sequences - sequenceT are the corollary of #1 above (plain-old JS arrays) * 3.9.19 Arrays - T[] are the corollary of #2 above; array-like and even are participate in the Array.prototype chain. In section 4.2.20, the following note outlines the difference between the so-called platform array object and a vanilla JS array: Note Platform array objects differ from Array objects in the following ways: - they are never sparse - their elements are always data properties - an ECMAScript-to-IDL value conversion is always performed when storing an element - their internal [[Class]] property value is different - their internal [[Extensible]] property value is always true Can we pick one of these as a starting point for .find()/.findAll()? For consistency with other DOM APIs, I personally see the platform array object as the way forward. [1] http://dev.w3.org/2006/webapi/WebIDL/#idl-sequence
