Re: [IndexedDB] Compound and multiple keys
Getting pgsql people involved sounds a great idea. Having some more people to argue for formalised and standardised database APIs like SQL, and experience with relational operations and optimisation would be good (That is an assumption on my part, but then they are writing PostgreSQL not CouchDB). Do you know some people you could invite? More generally though, I think BerkeleyDB would make a much better target for IDB. I don't think it should be trying to be PostgreSQL or MySQL. I think that implementing a good low-level API like BerkeleyDB that has enough functionality to allow SQL to be implemented over the top. The problem with trying to implement IDB on top of PostgreSQL is that IDB has a very narrow interface, that does not support any of the powerful features of pgsql. It would give you the worst of both. BDB would make a much implementation. Far more sensible would be to target the feature set of BDB for IDB, then PostgreSQL could be re-implemented in JavaSctipt on top. (a massive and impractical task, but I am trying to express the relationship between high level and low level database APIs). If we wanted to go fully relational, and avoid the correctness problems with string processing SQL commands, take a look at my relational library, currently implemented on top of WebSQL but an IDB version is in the works: https://github.com/keean/RelationalDB Cheers, Keean. On 9 March 2011 04:10, Charles Pritchard ch...@jumis.com wrote: On 3/8/2011 6:12 PM, Jeremy Orlow wrote: On Tue, Mar 8, 2011 at 5:55 PM, Pablo Castro pablo.cas...@microsoft.comwrote: From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Keean Schupke Sent: Tuesday, March 08, 2011 3:03 PM No objections here. Keean. On 8 March 2011 21:14, Jonas Sicking jo...@sicking.ccjo...@sicking.ccwrote: On Mon, Mar 7, 2011 at 10:43 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Jan 21, 2011 at 1:41 AM, Jeremy Orlow jor...@chromium.org wrote: After thinking about it a bunch and talking to others, I'm actually leaning towards both option A and B. Although this will be a little harder for implementors, it seems like there are solid reasons why some users would want to use A and solid reasons why others would want to use B. Any objections to us going that route? Not from me. If I don't hear objections I'll write up a spec draft and attach it here before committing to the spec. Option A is pretty well understood, I like that one. For option B, at some point we had a debate on whether when indexing an array value we should consider it a single key value or we should unfold it into multiple index records. The first option makes it very similar to A in that an array is just a composite value (it is quite a bit more painful to implement...), the second option is interesting in that allows for new scenarios such as objects with an array for tags, where you want to look up by tag (even after doing options A and B as currently defined, in order support multiple tags you'd need a second store that keeps the tags + key for the objects you want to tag). Is there any interest in that scenario? Yes. Once we're settled on this, I'm going to send an email on that. :-) Option b won't get in the way of my proposal. J At some point, I really would like to get people from the PostgreSQL project involved with indexeddb. They have a wealth of experience to bring to the discussion. For the moment, like many server-side packages, they're at quite a distance from the w3. FWIW, pgsql is a perfectly valid 'host' for idb calls.
Re: [IndexedDB] Compound and multiple keys
Keean/Charles: I definitely think the more people involved the better, but let's not get too hung up on the specifics of PostgreSQL, BDB, etc. Our goal here should be to make a great API for web developers while balancing practical considerations like how difficult it'll be to implement and/or use efficiently. That said, I'm not understanding what your comments have to do with this proposal. Do you have specific concerns? J On Wed, Mar 9, 2011 at 12:55 AM, Keean Schupke ke...@fry-it.com wrote: Getting pgsql people involved sounds a great idea. Having some more people to argue for formalised and standardised database APIs like SQL, and experience with relational operations and optimisation would be good (That is an assumption on my part, but then they are writing PostgreSQL not CouchDB). Do you know some people you could invite? More generally though, I think BerkeleyDB would make a much better target for IDB. I don't think it should be trying to be PostgreSQL or MySQL. I think that implementing a good low-level API like BerkeleyDB that has enough functionality to allow SQL to be implemented over the top. The problem with trying to implement IDB on top of PostgreSQL is that IDB has a very narrow interface, that does not support any of the powerful features of pgsql. It would give you the worst of both. BDB would make a much implementation. Far more sensible would be to target the feature set of BDB for IDB, then PostgreSQL could be re-implemented in JavaSctipt on top. (a massive and impractical task, but I am trying to express the relationship between high level and low level database APIs). If we wanted to go fully relational, and avoid the correctness problems with string processing SQL commands, take a look at my relational library, currently implemented on top of WebSQL but an IDB version is in the works: https://github.com/keean/RelationalDB Cheers, Keean. On 9 March 2011 04:10, Charles Pritchard ch...@jumis.com wrote: On 3/8/2011 6:12 PM, Jeremy Orlow wrote: On Tue, Mar 8, 2011 at 5:55 PM, Pablo Castro pablo.cas...@microsoft.comwrote: From: public-webapps-requ...@w3.org [mailto: public-webapps-requ...@w3.org] On Behalf Of Keean Schupke Sent: Tuesday, March 08, 2011 3:03 PM No objections here. Keean. On 8 March 2011 21:14, Jonas Sicking jo...@sicking.ccjo...@sicking.ccwrote: On Mon, Mar 7, 2011 at 10:43 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Jan 21, 2011 at 1:41 AM, Jeremy Orlow jor...@chromium.org wrote: After thinking about it a bunch and talking to others, I'm actually leaning towards both option A and B. Although this will be a little harder for implementors, it seems like there are solid reasons why some users would want to use A and solid reasons why others would want to use B. Any objections to us going that route? Not from me. If I don't hear objections I'll write up a spec draft and attach it here before committing to the spec. Option A is pretty well understood, I like that one. For option B, at some point we had a debate on whether when indexing an array value we should consider it a single key value or we should unfold it into multiple index records. The first option makes it very similar to A in that an array is just a composite value (it is quite a bit more painful to implement...), the second option is interesting in that allows for new scenarios such as objects with an array for tags, where you want to look up by tag (even after doing options A and B as currently defined, in order support multiple tags you'd need a second store that keeps the tags + key for the objects you want to tag). Is there any interest in that scenario? Yes. Once we're settled on this, I'm going to send an email on that. :-) Option b won't get in the way of my proposal. J At some point, I really would like to get people from the PostgreSQL project involved with indexeddb. They have a wealth of experience to bring to the discussion. For the moment, like many server-side packages, they're at quite a distance from the w3. FWIW, pgsql is a perfectly valid 'host' for idb calls.
Widget URI tests
Hi all, I¹m working to develop some widget URI tests. I notice there is nothing yet linked from the pubstatus page. I¹ve attached a widget which performs one simple test: verify if the window¹s location.protocol attribute is ³widget:². This was modeled upon the widget interface tests. It passes under Opera 11.01. Looking into the other normative requirements, I¹d like the group¹s input on what other requirements in the Widgets URI spec would be considered high-priority for an ³Acid test² level of support validation. Thanks, Bryan Sullivan | ATT WAC2_WS1410.wgt Description: Binary data
Re: [IndexedDB] Compound and multiple keys
I have already said I have no specific concerns regarding this change. Its difficult to predict problems that will emerge when people actually try and use an API. That's why there are so many bad APIs out there. One way to mitigate this risk is to look at well used existing APIs (in languages like 'c') to see what works well. Many people often write different APIs for the same task, and the best win. I would look to existing winners (like BDB) for guidance on the total API, as due to the standardisation process (and the nature of web browsers) there is no opportunity for competition to choose the best API. It would be nice if jsnode was more advanced, then there might be many database API implementations in JavaScript we could look at to see which are preferred and use as a starting point. Looking at the requirements for IDB, BerkeleyDB would seem to be an ideal candidate to port the API, its popular, widely used and has stood the test of time, and is easy to use, and would be even easier in JavaScript with garbage collection. Cheers, Keean. On 9 March 2011 09:41, Jeremy Orlow jor...@chromium.org wrote: Keean/Charles: I definitely think the more people involved the better, but let's not get too hung up on the specifics of PostgreSQL, BDB, etc. Our goal here should be to make a great API for web developers while balancing practical considerations like how difficult it'll be to implement and/or use efficiently. That said, I'm not understanding what your comments have to do with this proposal. Do you have specific concerns? J On Wed, Mar 9, 2011 at 12:55 AM, Keean Schupke ke...@fry-it.com wrote: Getting pgsql people involved sounds a great idea. Having some more people to argue for formalised and standardised database APIs like SQL, and experience with relational operations and optimisation would be good (That is an assumption on my part, but then they are writing PostgreSQL not CouchDB). Do you know some people you could invite? More generally though, I think BerkeleyDB would make a much better target for IDB. I don't think it should be trying to be PostgreSQL or MySQL. I think that implementing a good low-level API like BerkeleyDB that has enough functionality to allow SQL to be implemented over the top. The problem with trying to implement IDB on top of PostgreSQL is that IDB has a very narrow interface, that does not support any of the powerful features of pgsql. It would give you the worst of both. BDB would make a much implementation. Far more sensible would be to target the feature set of BDB for IDB, then PostgreSQL could be re-implemented in JavaSctipt on top. (a massive and impractical task, but I am trying to express the relationship between high level and low level database APIs). If we wanted to go fully relational, and avoid the correctness problems with string processing SQL commands, take a look at my relational library, currently implemented on top of WebSQL but an IDB version is in the works: https://github.com/keean/RelationalDB Cheers, Keean. On 9 March 2011 04:10, Charles Pritchard ch...@jumis.com wrote: On 3/8/2011 6:12 PM, Jeremy Orlow wrote: On Tue, Mar 8, 2011 at 5:55 PM, Pablo Castro pablo.cas...@microsoft.com wrote: From: public-webapps-requ...@w3.org [mailto: public-webapps-requ...@w3.org] On Behalf Of Keean Schupke Sent: Tuesday, March 08, 2011 3:03 PM No objections here. Keean. On 8 March 2011 21:14, Jonas Sicking jo...@sicking.ccjo...@sicking.ccwrote: On Mon, Mar 7, 2011 at 10:43 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Jan 21, 2011 at 1:41 AM, Jeremy Orlow jor...@chromium.org wrote: After thinking about it a bunch and talking to others, I'm actually leaning towards both option A and B. Although this will be a little harder for implementors, it seems like there are solid reasons why some users would want to use A and solid reasons why others would want to use B. Any objections to us going that route? Not from me. If I don't hear objections I'll write up a spec draft and attach it here before committing to the spec. Option A is pretty well understood, I like that one. For option B, at some point we had a debate on whether when indexing an array value we should consider it a single key value or we should unfold it into multiple index records. The first option makes it very similar to A in that an array is just a composite value (it is quite a bit more painful to implement...), the second option is interesting in that allows for new scenarios such as objects with an array for tags, where you want to look up by tag (even after doing options A and B as currently defined, in order support multiple tags you'd need a second store that keeps the tags + key for the objects you want to tag). Is there any interest in that scenario? Yes. Once we're settled on this, I'm going to send an email on that. :-) Option b won't get in the way of my
Re: Overview of W3C technologies for mobile Web applications
Hi Charles, Le mardi 08 mars 2011 à 21:14 -0800, Charles Pritchard a écrit : InkML is a development relevant to mobile Web. Tablets and other input-rich devices are gaining in acceptance (and becoming easier to purchase). InkML is one of the few specs to put forward both a stream-based and archive-oriented format. I see that there is ongoing discussions around the relationship between InkML and DOM touch events: http://lists.w3.org/Archives/Public/www-multimodal/2011Feb/0004.html This may indeed make InkML a promising lead for capturing user input; I'll see if I find a way to integrate it in the mobile web apps standards document http://www.w3.org/2011/02/mobile-web-app-state.html If anyone has more input on how developers would actually use InkML as part of their Web applications on mobile devices, that would be most useful. Thanks, Dom
Re: [FileAPI] Why is FileList a sequence?
On Tue, 08 Mar 2011 19:47:47 +0100, Arun Ranganathan a...@mozilla.com wrote: Do you disagree that FileList should be a sequence parametrized type? I think the construct of a parametrized type makes a lot of sense. But it should work like the types we have to date, so that NodeList, StyleSheetList, CSSRuleList, etc. can actually be defined (and implemented) as one. Introducing a completely new type with different behavior is not worth it. -- Anne van Kesteren http://annevankesteren.nl/
Moving XBL et al. forward
Ian, Leigh, Dimitri, All, On March 11, the agenda of the so-called Hypertext Coordination Group [HCG] will include XBL [XBL] to continue related discussions they had during their Feb 11 call [Feb-11-Mins]. I wasn't present at that call but based on those meeting minutes and what Leigh said last month [Leigh], I think the gist of the March 11 discussion will revolve around: * What is the latest implementation status of the XBL2 CR [XBL2-CR] and Hixie's September 2010 version [XBL-ED] (previously referred to as XBL2-cutdown)? * Which members of WebApps want to continue with the XML-based version of XBL2 as codified in the XBL2 CR? If you are groupin this , what firm commitments can you make to push the spec along the REC track? Would you object to the Forms WG taking over this spec? * Which members of WebApps want to continue with the non-XML version as Hixie created last September? If you are in this group, what firm commitments can you make to push this version along the REC track (especially implementation)? * Should the WG pursue Dimitri Glazkov's Component Model proposal [Component]? If yes, who is willing to commit to work on that spec? Please send comments on the above as soon as possible (preferably before 10:00am Boston time on March 11). -Art Barstow [XBL] http://www.w3.org/2008/webapps/wiki/XBL [HCG] http://www.w3.org/MarkUp/CoordGroup/ [Feb-11-Mins] http://lists.w3.org/Archives/Public/public-hypertext-cg/2011JanMar/0007.html [Leigh] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0243.html [XBL2-CR] http://www.w3.org/TR/2007/CR-xbl-20070316/ [XBL2-ED] http://dev.w3.org/2006/xbl2/ [Component] http://wiki.whatwg.org/wiki/Component_Model_Use_Cases
Re: Moving XBL et al. forward
On 03/09/2011 04:14 PM, Arthur Barstow wrote: Ian, Leigh, Dimitri, All, On March 11, the agenda of the so-called Hypertext Coordination Group [HCG] will include XBL [XBL] to continue related discussions they had during their Feb 11 call [Feb-11-Mins]. I wasn't present at that call but based on those meeting minutes and what Leigh said last month [Leigh], I think the gist of the March 11 discussion will revolve around: * What is the latest implementation status of the XBL2 CR [XBL2-CR] and Hixie's September 2010 version [XBL-ED] (previously referred to as XBL2-cutdown)? * Which members of WebApps want to continue with the XML-based version of XBL2 as codified in the XBL2 CR? I'd like us to continue in this path. If you are groupin this , what firm commitments can you make to push the spec along the REC track? Not sure. Would you object to the Forms WG taking over this spec? Yes. * Which members of WebApps want to continue with the non-XML version as Hixie created last September? If you are in this group, what firm commitments can you make to push this version along the REC track (especially implementation)? * Should the WG pursue Dimitri Glazkov's Component Model proposal [Component]? What is the proposal? The linked document is about use cases, or more like requirements to XBL2 If yes, who is willing to commit to work on that spec? Please send comments on the above as soon as possible (preferably before 10:00am Boston time on March 11). -Art Barstow [XBL] http://www.w3.org/2008/webapps/wiki/XBL [HCG] http://www.w3.org/MarkUp/CoordGroup/ [Feb-11-Mins] http://lists.w3.org/Archives/Public/public-hypertext-cg/2011JanMar/0007.html [Leigh] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0243.html [XBL2-CR] http://www.w3.org/TR/2007/CR-xbl-20070316/ [XBL2-ED] http://dev.w3.org/2006/xbl2/ [Component] http://wiki.whatwg.org/wiki/Component_Model_Use_Cases
RE: publish Last Call Working Draft of Progress Events spec; deadline March 7
Microsoft supports this. From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Wednesday, March 02, 2011 4:08 AM To: public-webapps Subject: CfC: publish Last Call Working Draft of Progress Events spec; deadline March 7 Given no comments were submitted during the 2-week pre-LC comment period [1] for the Progress Events spec, this is a Call for Consensus to publish a Last Call Working Draft of this spec based on the latest Editor's Draft: http://dev.w3.org/2006/webapi/progress/Progress.html This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. The deadline for comments is March 9. Please send all comments to: public-webapps@w3.orgmailto:public-webapps@w3.org Assuming there is consensus to publish this LCWD, the tentative plan is to publish it on March 10 with a the LC comment period ending June 1. -Art Barstow
RE: publish Last Call Working Draft of Web Workers; deadline March 7
Apologies for missing the March 7 deadline. We tried to carry out a detailed
pre-Last
Call review and have the following feedback. Microsoft would like to discuss
these
points before moving the Last Call.
Thanks,
Adrian.
Feedback on latest draft of Web Workers
Based on our understanding of the web worker lifetime model (Section 4.4),
dedicated
workers are allowed to enter into an orphaned state where they have a message
port
that is keeping them alive (see example at the end of this feedback). We can
imagine
scenarios where the orphaned workers are still able to provide results to a
document
(e.g., via connecting to a shared worker), however these use cases 1) seem
largely
irrelevant, 2) can be handled by shared workers if needed and 3) overly
complicate the
implementation (in our analysis) of dedicated workers.
We note that no browser appears to implement the lifetime model as specified in
the
latest editor's draft (that we can test).
As we've investigated potential alternate lifetime models (for dedicated
workers only),
we came up with two additional potential models:
1 - Lifetime based on a dedicated worker's document reachability
This alternate lifetime model keeps a dedicated worker alive until it can no
longer
communicate with the document(s) to which it is associated (through its
implicit port
or any other port). This proposed lifetime model is based on graph
reachability, where
the nodes in the graph are web workers and the arcs in the graph are implicit
and
explicit message ports owned by a worker (i.e., the worker's ports). A
dedicated
worker's lifetime is managed by whether the dedicated worker can reach the
document(s) in its list of the worker's documents. See the example at the end
for
how the currently speced lifetime model changes with this approach.
2 - Lifetime that prevents orphaning dedicated workers
In this alternate lifetime model, orphaned dedicated workers are never allowed,
and
the lifetime of the worker is strictly controlled by its implicit port.
Therefore,
whenever a worker creates another worker, if the parent worker is terminated
or
closed, then the child worker will be terminated or closed as well
(preventing the
child from becoming an orphan). This model is enforced regardless of other
message
ports that the child may have.
It is our opinion that the lifetime model for dedicated workers as currently
speced:
1. Overly complicates the implementation
2. Supports corner-case scenarios that have questionable mainstream benefit,
compared to the perception of the currently specified design being
considered a
bug (e.g., the web developer creates a scenario where the orphaned worker
remains
alive, but did not actually intend for this to happen)
3. Provides overlapping scenarios with shared workers (e.g., if the web
developer
really intended the dedicated workers to remain alive as orphans, then
they could
use a shared worker to accomplish the same task instead)
We ask that this feedback be considered and are specifically looking for
1) a justification of the scenarios enabled by supporting dedicated workers in
an
orphaned state and 2) scenarios we may not have considered where an orphaned
dedicated
worker could not be substituted for a shared worker to accomplish the same task.
Should a change to the spec be made as a result of this feedback, we would
propose
that alternate lifetime model #2 above be considered instead (not allowing
orphaned
dedicated workers). Alternate approach #1, while less of a change, is
considerably
harder to implement than #2 given the graph reachability problem involved.
It is also worth noting that current versions of Opera appear to implement the
dedicated worker alternate lifetime model #2 above, though we don't know what
decisions led to that conclusion from their point of view.
Example that creates an orphaned dedicated workers:
Steps:
1. Document 'D' creates dedicated worker 'W1'
2. Dedicated worker W1 creates a dedicated worker 'W2'
3. Document 'D' creates dedicated worker 'W3'
4. Dedicated worker W3 creates a dedicated worker 'W4'
(At this point W1 and W3 are parent workers and W2 and W4 are child
workers.)
5. W1 creates a message channel and passes the channel's ports to document
'D' and 'W2'
6. W3 creates a message channel and passes the channel's ports to document
'D' and 'W4'
('D' now has an independent message port for W2 and W4.)
7. Document 'D' creates a message channel and passes the channel's ports to
'W2' and 'W4'
(W2 and W4 now have a direct communication channel between themselves.)
8. Document 'D' terminates worker 'W1'
(Terminating W1 causes all W1's ports to be disentangled [step 15 of
section 4.5
processing model] which effects W2's implicit port; however, W2 is not
terminated
because it is still considered a protected worker, since its list of the
worker's
ports is not empty.)
9.
RE: to stop work on Programmable HTTP Caching and Serving spec; deadline March 10
Microsoft supports this CfC. From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Thursday, March 03, 2011 5:26 AM To: public-webapps Cc: Mark Nottingham; Julian Reschke; Nikunj Mehta Subject: CfC: to stop work on Programmable HTTP Caching and Serving spec; deadline March 10 Hi All, WebApps' Programmable HTTP Caching and Serving spec was last updated by Nikunj in January 2010. Since then, my attempt to determine the level of interest in this spec via the tread below (archived at [1]) received no real traction. As such, this is a Call for Consensus to formally stop work on this spec. More specifically, the proposal includes: 1. Moving the spec from the PubStatus' active API Specifications table [2] to the Specs NO Longer Active table [3] 2. Marking its Plans data with Work on the specification has ended 3. Removing it from WebApps' charter the next time the charter is renewed (current charter ends June 2012) Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. The deadline for comments is March 10. Please send all comments to: public-webapps@w3.orgmailto:public-webapps@w3.org -Art Barstow [1] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0447.html [2] http://www.w3.org/2008/webapps/wiki/PubStatus#API_Specifications [3] http://www.w3.org/2008/webapps/wiki/PubStatus#Specs_NO_Longer_Active Original Message Subject: [DataCache] Status and plans for Programmable HTTP Caching and Serving? Date: Fri, 5 Nov 2010 14:26:13 +0100 From: Barstow Art (Nokia-CIC/Boston) art.bars...@nokia.commailto:art.bars...@nokia.com To: public-webapps public-webapps@w3.orgmailto:public-webapps@w3.org, Nikunj Mehta nik...@o-micron.commailto:nik...@o-micron.com, Bernard Traversat bernard.traver...@oracle.commailto:bernard.traver...@oracle.com, Julian Reschke julian.resc...@gmx.demailto:julian.resc...@gmx.de, Mark Nottingham m...@yahoo-inc.commailto:m...@yahoo-inc.com Hi All, During WebApps' November 1 gathering at the TPAC, we discussed [Mins] the WG's Programmable HTTP Caching and Serving spec, last updated by Nikunj in January 2010 [DataCache]. During this discussion, I agreed to the following related actions: ACTION-599 Ask Nikunj to report the status and plans of Programmable Cache to public-webapps http://www.w3.org/2008/webapps/track/actions/599 ACTION-600 Ask Oracle about their level of interest in Programmable Cache http://www.w3.org/2008/webapps/track/actions/600 ACTION-601 Ask public-webapps about creating Use Cases and requirements of Program App Caches versus HTML5 App Cache http://www.w3.org/2008/webapps/track/actions/601 ACTION-602 Contact julian reschke and Mark Nottingham about Data Cache http://www.w3.org/2008/webapps/track/actions/602 My short summary of this discussion is: it isn't clear if there is sufficient interest to continue this spec and if there is interest, what are the specific use cases it will address (i.e. use cases not addressed by HTML5 AppCache), and who is willing to commit to drive the spec forward. -Art Barstow [ tracker tags: ACTION-599, ACTION-600, ACTION-601, ACTION-602 ] [Mins] http://www.w3.org/2010/11/01-webapps-minutes.html#item05 [DataCache] http://dev.w3.org/2006/webapi/DataCache/
Re: publish Last Call Working Draft of Web Workers; deadline March 7
Adrian - the timing of your email is unfortunate. The publication
process has already started so we will consider your comments as LC
comments.
-Art Barstow
On Mar/9/2011 9:58 AM, ext Adrian Bateman wrote:
Apologies for missing the March 7 deadline. We tried to carry out a detailed
pre-Last
Call review and have the following feedback. Microsoft would like to discuss
these
points before moving the Last Call.
Thanks,
Adrian.
Feedback on latest draft of Web Workers
Based on our understanding of the web worker lifetime model (Section 4.4),
dedicated
workers are allowed to enter into an orphaned state where they have a message
port
that is keeping them alive (see example at the end of this feedback). We can
imagine
scenarios where the orphaned workers are still able to provide results to a
document
(e.g., via connecting to a shared worker), however these use cases 1) seem
largely
irrelevant, 2) can be handled by shared workers if needed and 3) overly
complicate the
implementation (in our analysis) of dedicated workers.
We note that no browser appears to implement the lifetime model as specified in the
latest editor's draft (that we can test).
As we've investigated potential alternate lifetime models (for dedicated workers only),
we came up with two additional potential models:
1 - Lifetime based on a dedicated worker's document reachability
This alternate lifetime model keeps a dedicated worker alive until it can no
longer
communicate with the document(s) to which it is associated (through its
implicit port
or any other port). This proposed lifetime model is based on graph
reachability, where
the nodes in the graph are web workers and the arcs in the graph are implicit
and
explicit message ports owned by a worker (i.e., the worker's ports). A
dedicated
worker's lifetime is managed by whether the dedicated worker can reach the
document(s) in its list of the worker's documents. See the example at the end
for
how the currently speced lifetime model changes with this approach.
2 - Lifetime that prevents orphaning dedicated workers
In this alternate lifetime model, orphaned dedicated workers are never allowed,
and
the lifetime of the worker is strictly controlled by its implicit port.
Therefore,
whenever a worker creates another worker, if the parent worker is terminated
or
closed, then the child worker will be terminated or closed as well
(preventing the
child from becoming an orphan). This model is enforced regardless of other
message
ports that the child may have.
It is our opinion that the lifetime model for dedicated workers as currently speced:
1. Overly complicates the implementation
2. Supports corner-case scenarios that have questionable mainstream benefit,
compared to the perception of the currently specified design being
considered a
bug (e.g., the web developer creates a scenario where the orphaned worker
remains
alive, but did not actually intend for this to happen)
3. Provides overlapping scenarios with shared workers (e.g., if the web
developer
really intended the dedicated workers to remain alive as orphans, then
they could
use a shared worker to accomplish the same task instead)
We ask that this feedback be considered and are specifically looking for
1) a justification of the scenarios enabled by supporting dedicated workers in
an
orphaned state and 2) scenarios we may not have considered where an orphaned
dedicated
worker could not be substituted for a shared worker to accomplish the same task.
Should a change to the spec be made as a result of this feedback, we would propose
that alternate lifetime model #2 above be considered instead (not allowing
orphaned
dedicated workers). Alternate approach #1, while less of a change, is
considerably
harder to implement than #2 given the graph reachability problem involved.
It is also worth noting that current versions of Opera appear to implement the
dedicated worker alternate lifetime model #2 above, though we don't know what
decisions led to that conclusion from their point of view.
Example that creates an orphaned dedicated workers:
Steps:
1. Document 'D' creates dedicated worker 'W1'
2. Dedicated worker W1 creates a dedicated worker 'W2'
3. Document 'D' creates dedicated worker 'W3'
4. Dedicated worker W3 creates a dedicated worker 'W4'
(At this point W1 and W3 are parent workers and W2 and W4 are child
workers.)
5. W1 creates a message channel and passes the channel's ports to document
'D' and 'W2'
6. W3 creates a message channel and passes the channel's ports to document
'D' and 'W4'
('D' now has an independent message port for W2 and W4.)
7. Document 'D' creates a message channel and passes the channel's ports to
'W2' and 'W4'
(W2 and W4 now have a direct communication channel between themselves.)
8. Document 'D' terminates worker 'W1'
(Terminating W1 causes all W1's ports to be
Re: [FileAPI] Why is FileList a sequence?
On 3/9/11 7:12 AM, Anne van Kesteren wrote: On Tue, 08 Mar 2011 19:47:47 +0100, Arun Ranganathan a...@mozilla.com wrote: Do you disagree that FileList should be a sequence parametrized type? I think the construct of a parametrized type makes a lot of sense. But it should work like the types we have to date, so that NodeList, StyleSheetList, CSSRuleList, etc. can actually be defined (and implemented) as one. Introducing a completely new type with different behavior is not worth it. Point well taken -- I thought that parametrized types would replace earlier constructs. I'll make the change back. -- A*
Re: Moving XBL et al. forward
This email is written as the position of several Chrome engineers working in this problem area at Google, though not Google's official position. On Wed, Mar 9, 2011 at 6:14 AM, Arthur Barstow art.bars...@nokia.com wrote: * What is the latest implementation status of the XBL2 CR [XBL2-CR] and Hixie's September 2010 version [XBL-ED] (previously referred to as XBL2-cutdown)? Chrome does not implement either form of XBL2. * Which members of WebApps want to continue with the XML-based version of XBL2 as codified in the XBL2 CR? If you are groupin this , what firm commitments can you make to push the spec along the REC track? Would you object to the Forms WG taking over this spec? We object to continuing with XBL2. The original XBL2 was flawed, and the cutdown version of XBL2 is incomplete and still too complex. I'm not sure if we would object, per se, to the Forms WG taking over XBL2, but we would consider it wasted effort that would not result in us implementing it in Chrome/Webkit. * Which members of WebApps want to continue with the non-XML version as Hixie created last September? If you are in this group, what firm commitments can you make to push this version along the REC track (especially implementation)? We do not wish to work on either version of XBL2. * Should the WG pursue Dimitri Glazkov's Component Model proposal [Component]? If yes, who is willing to commit to work on that spec? We believe that the Component Model proposal should be pursued. Dimitri Glazkov volunteers to edit the spec. ~TJ
[Bug 12272] New: Improve section on DNS spoofing attacks to address user attacks
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12272 Summary: Improve section on DNS spoofing attacks to address user attacks Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Web Storage (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: wats...@netflix.com QAContact: member-webapi-...@w3.org CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org Section 7.1 on DNS spoofing attacks states: Pages using TLS can be sure that only pages using TLS that have certificates identifying them as being from the same domain can access their storage areas. We could add This protects against DNS spoofing attacks which do not involve the user. However, if the user is involved in the attack this protection can be circumvented by the user installing root certificates for fake certification authorities and then creating site certificates to be used in conjunction with DNS spoofing. Therefore a web page author cannot be sure that the information stored in web storage has not been viewed or modified by or on behalf of the user. i.e. page authors should be aware that even with TLS information inside web storage can be viewed and modified by or on behalf of the user. -- 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: Moving XBL et al. forward
On Wed, Mar 9, 2011 at 9:39 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: This email is written as the position of several Chrome engineers working in this problem area at Google, though not Google's official position. On Wed, Mar 9, 2011 at 6:14 AM, Arthur Barstow art.bars...@nokia.com wrote: * What is the latest implementation status of the XBL2 CR [XBL2-CR] and Hixie's September 2010 version [XBL-ED] (previously referred to as XBL2-cutdown)? Chrome does not implement either form of XBL2. * Which members of WebApps want to continue with the XML-based version of XBL2 as codified in the XBL2 CR? If you are groupin this , what firm commitments can you make to push the spec along the REC track? Would you object to the Forms WG taking over this spec? We object to continuing with XBL2. The original XBL2 was flawed, and the cutdown version of XBL2 is incomplete and still too complex. I'm not sure if we would object, per se, to the Forms WG taking over XBL2, but we would consider it wasted effort that would not result in us implementing it in Chrome/Webkit. To be fair, most of the event retargeting, CSS property inheritance and the plumbing for custom pseudo element capability (XBL2's pseudo attribute) is now implemented in WebKit. So there is _some_ overlap in the mechanical (i.e. non-user-facing) parts of the spec. I view [XBL2-ED] spec as an excellent starting point for the Web Components spec, but we should go much further toward untangling orthogonal concerns and simplifying, as well as relying more on existing (and well-understood) concepts in the Web platform. * Which members of WebApps want to continue with the non-XML version as Hixie created last September? If you are in this group, what firm commitments can you make to push this version along the REC track (especially implementation)? We do not wish to work on either version of XBL2. * Should the WG pursue Dimitri Glazkov's Component Model proposal [Component]? If yes, who is willing to commit to work on that spec? We believe that the Component Model proposal should be pursued. Dimitri Glazkov volunteers to edit the spec. I certainly do, although the link mentioned is not really a proposal, more like a clean-slate examination of the concrete use cases that a Web Component model should satisfy. ~TJ
Re: Using ArrayBuffer as payload for binary data to/from Web Workers
On Mar 7, 2011, at 6:07 PM, Boris Zbarsky wrote: On 3/7/11 8:55 PM, Glenn Maynard wrote: I'd expect CanvasPixelArray to allow optimizations that ArrayBuffer doesn't, since the implementation can use the native surface format, translating to RGBA for the script transparently. This can matter for streaming textures to OpenGL/D3D, too; creating BGRA textures on nVidia hardware is typically much faster than RGBA ones. But modifying the ImageData is not supposed to modify what the graphics card sees, right? So you have to make a copy here on putImageData (or on the next write to the image data), right? I don't recall if this has been brought up: are there cases where explicit zero-copy messaging is better than transparent copy-on-write? Transparent copy on write requires that each write do a should I copy? check, right? Yeah, nothing's free, unless you have copy-on-write hardware or something. - ~Chris cmar...@apple.com
Re: Using ArrayBuffer as payload for binary data to/from Web Workers
On Mar 7, 2011, at 7:12 PM, Glenn Maynard wrote: On Mon, Mar 7, 2011 at 9:07 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/7/11 8:55 PM, Glenn Maynard wrote: I'd expect CanvasPixelArray to allow optimizations that ArrayBuffer doesn't, since the implementation can use the native surface format, translating to RGBA for the script transparently. This can matter for streaming textures to OpenGL/D3D, too; creating BGRA textures on nVidia hardware is typically much faster than RGBA ones. But modifying the ImageData is not supposed to modify what the graphics card sees, right? So you have to make a copy here on putImageData (or on the next write to the image data), right? Right, either way you need to make a copy when you send the data back to the canvas. But, if the surface format of the memory buffer matches a native format of the graphics card, the copy is very fast--probably a DMA, for hardware-accelerated surfaces. (The exact mechanics of this are hidden behind the drivers, of course, but that's what it looks like in my experience.) For example, nVidia cards typically are BGRA natively, and if you give them RGBA with OpenGL it needs to be converted before (or as) it's copied, which is much slower. (Of course, CanvasPixelData itself always has to *appear* RGBA, but that doesn't mean the backing store needs to actually be RGBA.) I don't recall if this has been brought up: are there cases where explicit zero-copy messaging is better than transparent copy-on-write? Transparent copy on write requires that each write do a should I copy? check, right? Yeah. The question is probably whether that check can be moved out of inner loops. It couldn't be if function calls are made that might have side-effects to cause a private object to become a COW object (eg. non-pure functions). For page-aligned buffers, an implementation could optimize these checks away entirely by marking the buffer read-only, so if a write is made it'll raise an exception that the engine can catch. Yes. Copy on write does not efficiently handle the case where large amounts of data are continually produced by workers and posted to the main thread for display. Each time the worker posts a block of data to the main thread, the next time it attempts to update its version of the block for the next iteration, a copy will need to be made so the main thread's version appears immutable. But how is this any different than just throwing away the ArrayBuffer and creating a fresh one after each postMessage? You can't throw away the ArrayBuffer, since the sender still has a reference to it. The proposal we've tossed around would make that ArrayBuffer 0 length, which I suppose is conceptually throwing it away since you can't add a fresh buffer to ArrayBuffer. So maybe it would be better if ArrayBuffer still has the same length but now points at a new buffer of data. This could be done lazily so the buffer need not be allocated until accessed. - ~Chris cmar...@apple.com
Re: Moving XBL et al. forward
On Wed, 09 Mar 2011 15:14:48 +0100, Arthur Barstow art.bars...@nokia.com wrote: * Which members of WebApps want to continue with the XML-based version of XBL2 as codified in the XBL2 CR? If you are groupin this , what firm commitments can you make to push the spec along the REC track? Would you object to the Forms WG taking over this spec? I do not think the XML-based version makes sense anymore. It's too complex and has always felt a bit awkward. A set of extensions to HTML or CSS would make more sense. I really quite liked the idea of using CSS and having some way of writing markup in CSS for this. Hopefully we can explore that somewhat. * Which members of WebApps want to continue with the non-XML version as Hixie created last September? If you are in this group, what firm commitments can you make to push this version along the REC track (especially implementation)? * Should the WG pursue Dimitri Glazkov's Component Model proposal [Component]? If yes, who is willing to commit to work on that spec? So far that is just a bunch of use cases, not really a proposal, but I really like how they are targeted at addressing issues such as form control styling. That is something authors want to see addressed, and was initially deferred to XBL3 or some such. [Component] http://wiki.whatwg.org/wiki/Component_Model_Use_Cases -- Anne van Kesteren http://annevankesteren.nl/
Re: Moving XBL et al. forward
On Wed, 9 Mar 2011, Arthur Barstow wrote: * What is the latest implementation status of the XBL2 CR [XBL2-CR] and Hixie's September 2010 version [XBL-ED] (previously referred to as XBL2-cutdown)? I'm not aware of any new developments on either front. * Which members of WebApps want to continue with the XML-based version of XBL2 as codified in the XBL2 CR? If you are groupin this , what firm commitments can you make to push the spec along the REC track? Would you object to the Forms WG taking over this spec? I have no objections to anyone continuing down such a path (the spec is under a Creative Commons license to allow anyone to do just that). I would ask that people use another name if they did, though, to avoid confusion. * Which members of WebApps want to continue with the non-XML version as Hixie created last September? If you are in this group, what firm commitments can you make to push this version along the REC track (especially implementation)? * Should the WG pursue Dimitri Glazkov's Component Model proposal [Component]? If yes, who is willing to commit to work on that spec? I expect XBL and Dimitri's work will evolve together and eventually end up being features specified in the HTML spec. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Moving XBL et al. forward
Here's my best understanding of the ansers to these questions from the Forms WG perspective: We continue to cheer for the development of a component system for the HTML5 stack, as it will make things easier for end-user authors and for framework developers, whether they choose to express their ideas in markup, JavaScript, or a mix. We do not feel it is necessary for the desktop and mobile browser implementations of a new component language to handle namespaced XML. However, as XForms is, and will continue to be, a markup-based layer to other W3C technologies, many of which will, going forward, be specified as JavaScript interfaces (XHR, DOM, etc.), we want to ensure that an extension or optional feature can be used to accept namespaced XML markup and produce output including namespaced XML markup. We expect to see XForms implemented in popular mobile and desktop browsers (as it currently is) in JavaScript, XSLT, and in server-side systems. Thus, a syntax that can cleanly be extended to bind to (and to produce) namespaced markup is important to us. Our hope is that the extensions necessary to express this will be minimal. While our preference would be to have this syntax described in the main component language recommendation, we can live it with being expressed in another recommendation which merely adds on the syntax. As for re-casting XBL as a series of CSS extensions, itself not expressed in markup, we have not discussed that issue yet, but if the proposal moves further forward we will. Leigh. On 03/09/2011 06:14 AM, Arthur Barstow wrote: Ian, Leigh, Dimitri, All, On March 11, the agenda of the so-called Hypertext Coordination Group [HCG] will include XBL [XBL] to continue related discussions they had during their Feb 11 call [Feb-11-Mins]. I wasn't present at that call but based on those meeting minutes and what Leigh said last month [Leigh], I think the gist of the March 11 discussion will revolve around: * What is the latest implementation status of the XBL2 CR [XBL2-CR] and Hixie's September 2010 version [XBL-ED] (previously referred to as XBL2-cutdown)? * Which members of WebApps want to continue with the XML-based version of XBL2 as codified in the XBL2 CR? If you are groupin this , what firm commitments can you make to push the spec along the REC track? Would you object to the Forms WG taking over this spec? * Which members of WebApps want to continue with the non-XML version as Hixie created last September? If you are in this group, what firm commitments can you make to push this version along the REC track (especially implementation)? * Should the WG pursue Dimitri Glazkov's Component Model proposal [Component]? If yes, who is willing to commit to work on that spec? Please send comments on the above as soon as possible (preferably before 10:00am Boston time on March 11). -Art Barstow [XBL] http://www.w3.org/2008/webapps/wiki/XBL [HCG] http://www.w3.org/MarkUp/CoordGroup/ [Feb-11-Mins] http://lists.w3.org/Archives/Public/public-hypertext-cg/2011JanMar/0007.html [Leigh] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0243.html [XBL2-CR] http://www.w3.org/TR/2007/CR-xbl-20070316/ [XBL2-ED] http://dev.w3.org/2006/xbl2/ [Component] http://wiki.whatwg.org/wiki/Component_Model_Use_Cases
Re: Using ArrayBuffer as payload for binary data to/from Web Workers
On 3/9/11 1:54 PM, Glenn Maynard wrote: Any system with memory protection can interrupt on write, which makes copy-on-write very close to free, as long as you can page-align the buffer. That's a pretty serious caveat, though. And you're assuming that memory meta-operations like set up a custom write interrupt handler for this page are free, which is not exactly the case as I understand it. -Boris
Re: Moving XBL et al. forward
On 3/9/11 1:56 PM, Anne van Kesteren wrote: I do not think the XML-based version makes sense anymore. It's too complex and has always felt a bit awkward. A set of extensions to HTML or CSS would make more sense. I really quite liked the idea of using CSS and having some way of writing markup in CSS for this. Hopefully we can explore that somewhat. I think there's an important point being missed here. CSS application to nodes that are not in documents is not defined. I'm not sure it's possible or desirable to define in good ways, even. If we want to use something XBL-like that persists across nodes being moved in a document, it needs to not be bound via CSS. If we want it to work for nodes that you created via createElement it needs to not be bound via CSS. This has been the #1 lesson we have learned with Mozilla's XBL1 implementation: the CSS binding mechanism has been the biggest problem with it, leading to weird behavior, gross timing-dependent hacks, and years and years of other problems. Whatever we do needs to NOT use CSS as the binding mechanism. -Boris
Re: Moving XBL et al. forward
Arthur Barstow: * Should the WG pursue Dimitri Glazkov's Component Model proposal [Component]? If yes, who is willing to commit to work on that spec? I promised Dmitri some use cases from the SVG WG’s perspective, but haven’t managed to get to working on these yet. Whatever solution we have in the end – and I personally am not really fussed about whether it is XBL2 as it was, or is now, or something new based on Dmitri’s requirements document – I would like it to be able to work without an HTML document present. I want to be able to write a document like svg … star cx=100 cy=100 points=5/ /svg or svg … my:star xmlns:star=… cx=100 cy=100 points=5/ /svg or svg … g class=star cx=100 cy=100 points=5/ /svg or svg … g binding=star cx=100 cy=100 points=5/ /svg (choosing g here because it’s kind of similar to a div), one of those. Sorry for not having more concrete comments yet. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Using ArrayBuffer as payload for binary data to/from Web Workers
On Wed, Mar 9, 2011 at 3:40 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/9/11 1:54 PM, Glenn Maynard wrote: Any system with memory protection can interrupt on write, which makes copy-on-write very close to free, as long as you can page-align the buffer. That's a pretty serious caveat, though. And you're assuming that memory meta-operations like set up a custom write interrupt handler for this page are free, which is not exactly the case as I understand it. I don't think the presence of an MMU is a serious caveat for an optional optimization (even an important one), and you only need to set it up when it turns into a COW buffer, not before each access. Either way I agree with a direct zero-copy based API rather than building on COW. No sense introducing this complexity to implementations if it won't actually make the API better. -- Glenn Maynard
Re: Moving XBL et al. forward
(off-list) On Wed, Mar 9, 2011 at 1:25 PM, Cameron McCormack c...@mcc.id.au wrote: svg … star cx=100 cy=100 points=5/ /svg svg x-star cx=100 cy=100 points=5/ /svg ~TJ
Re: Moving XBL et al. forward
Cameron McCormack: svg … star cx=100 cy=100 points=5/ /svg Tab Atkins Jr.: svg x-star cx=100 cy=100 points=5/ /svg Or that. :) I have the feeling that we don’t have agreed upon rules on how authors are allowed to extend the platform. Whatever we deem is the “proper” way for them to do so would be how I’d like it to happen in SVG. -- Cameron McCormack ≝ http://mcc.id.au/
Component Model is not an Isolation Model
Greetings, fellow Web-Platform-o-nauts, Summary: We need a proper Isolation Model for the Web. Component Model ain't it. Art's email prodded me to condensate some of brain ether accumulated while looking at the use cases. Here's some for ya. After a productive discussion with the Caja folks and some soul-searching, it appears that we should stay away from attempting to conflate isolation properties (such as origin restrictions or bullet-proof DOM membranes) from the component model properties (such as encapsulation and behavior attachment). From the perspective of the component, the isolation is unfairly punishing -- you can't use the outside DOM or even DOM element on which you're hoisted, you can't add methods to it, and you have to always imagine the membrane in order to build a proper mental model of what the heck you're trying to accomplish. From the perspective of the document, the isolation is too fiddly: it's rare that the level of isolation at the _individual_ component level is what's actually necessary. More likely, the isolation scope extends over a set of controls, a theme or just a pile of code. Having components isolated independently is unnecessarily complex and difficult to manage. Isolating components in bunches (a-la XBL documents) is also suboptimal, because it conflates modularity of controls with isolation boundaries. Moreover, after looking at Caja primitives, it was easy to surmise that as long as the component model API has a sound (i.e. non-crazy) design, its security/isolation can be: a) teased apart cleanly from the requirements of the component model; b) spec'd and implemented separately. This means that use cases http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Using_Shadow_DOM_Boundary_for_Isolation are not going to be addressed by the component model alone. However, it does _not_ mean that we shouldn't prioritize development of a proper isolation model. We merely should recognize that isolation and encapsulation are two different things. :DG
Re: Component Model is not an Isolation Model
On 3/9/11 7:30 PM, Dimitri Glazkov wrote: From the perspective of the component, the isolation is unfairly punishing -- you can't use the outside DOM or even DOM element on which you're hoisted, you can't add methods to it, and you have to always imagine the membrane in order to build a proper mental model of what the heck you're trying to accomplish. This is sort of a requirement for being able to use components that you don't trust to arbitrarily mess with your DOM though, no? Also, the component wants to keep the document from poking at its internals except via the APIs the component exposes, I would think. From the perspective of the document, the isolation is too fiddly: it's rare that the level of isolation at the _individual_ component level is what's actually necessary. I'm not sure what the fiddly issue is here... From the perspective of the document isolation should mean two things: 1) Cross-site components are safe to use. 2) You can't screw up and depend on implementation details of a component, because if you're calling something the component provides then you're using APIs the component explicitly exposed. Is there something I'm missing? Or are those things that fall under modularity or encapsulation in your message? If so, what are you thinking of in terms of isolation? -Boris
Re: Component Model is not an Isolation Model
On 3/9/11 10:29 PM, Ryosuke Niwa wrote: This is sort of a requirement for being able to use components that you don't trust to arbitrarily mess with your DOM though, no? We already have very complicated security mechanisms for frames, and the history of the Web tells us that it's really hard to get them right. Why can't we reuse the same mechanism instead of introducing new one? Isn't it as simple as putting an iframe in your component, no? You mean putting your component in an iframe, to address the issue I brought up above? I suppose that could be done, but that involves having an iframe for things you want to end up using components, which means the markup is suddenly polluted with these componentization hooks. I would expect that the actual isolation model UAs _implement_ will use the same infrastructure that frames do. But that doesn't mean we need actual frames in the markup. Also notice that we want a slightly different policy here from frames, in that components do need to be able to define some methods on the objects they're bound to, right? -Boris
