Re: Specs using Web IDL
On Sat, 27 Jun 2009 08:57:06 +0200, Cameron McCormack c...@mcc.id.au wrote: I’d like to know what specs are currently using Web IDL, so that I can keep abreast of what features are being used and help to review them. This is what I have so far: HTML 5 http://dev.w3.org/html5/spec/ Server-Sent Events http://dev.w3.org/html5/eventsource/ The Web Sockets API http://dev.w3.org/html5/websockets/ Web Storage http://dev.w3.org/html5/webstorage/ Web Workers http://dev.w3.org/html5/workers/ File Upload http://dev.w3.org/2006/webapi/FileUpload/publish/FileUpload.html XMLHttpRequest http://dev.w3.org/2006/webapi/XMLHttpRequest/ XMLHttpRequest Level 2 http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ Selectors API http://dev.w3.org/2006/webapi/selectors-api/ BONDI 1.0 / latest http://bondi.omtp.org/1.0/apis/ http://bondi.omtp.org/modules/ ES Operating System (though not really a spec) http://code.google.com/p/es-operating-system/ Are there any others people are aware of? Web DOM Core http://simon.html5.org/specs/web-dom-core This spec would probably benefit from being moved to W3C space. As it happens, I would like to know if someone is interested in editing Web DOM Core. Maybe someone from Apple or Mozilla? -- Simon Pieters Opera Software
Re: Web IDL syntax
On Tue, 30 Jun 2009 09:07:22 +0200, Cameron McCormack c...@mcc.id.au wrote: Cameron McCormack: Following are my half baked proposals. I’ve now baked all of these proposals into the spec, except for the one about allowing multiple module levels with a module declaration (i.e., ‘module a::b::c’). * Made ‘in’ optional http://dev.w3.org/2006/webapi/WebIDL/#idl-operations Having it optional will likely lead to inconsistently written IDLs, which can be confusing. I think it would be better to either require it (as legacy cruft, basically) or remove it altogether (the relevant IDLs will need to be rewritten anyway for the other changes). -- Simon Pieters Opera Software
Re: Window Modes todo
On Jul 16, 2009, at 04:46 , Cameron McCormack wrote: Robin Berjon: - I forget the original reasoning: is it useful that the event initialisers have canBubbleArg and cancelableArg since presumably no matter what parameter is passed they won't bubble and won't be cancellable? Shouldn’t canBubbleArg and cancelableArg be honoured when user script creates and dispatches an event? Even if events created by the implementation are always non-bubbling and non-cancellable. To be honest, I'm not entirely certain of the value in enabling user script creation of these events — but I guess that's another matter. What concerns me is that all the initFooEvent/NS that we have all over are all copied and pasted from one another, and it's not entirely clear to me that this is not cargo-culting as I can't seem to recall what motivation there is for all of that :) -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Specs using Web IDL
On Jul 16, 2009, at 11:27 , Simon Pieters wrote: Web DOM Core http://simon.html5.org/specs/web-dom-core This spec would probably benefit from being moved to W3C space. As it happens, I would like to know if someone is interested in editing Web DOM Core. Maybe someone from Apple or Mozilla? I have some interest in helping out with it, but I can't commit to being the single editor (unless you want it to move very slowly :). -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
[widgets] PC progression to CR
Art, Marcos, Please could you give us an update on the status of the progression of Widgets PC to CR? I noticed on the publication status page this is still marked as LCWD. We would like to see prompt progression of this work given the level of effort that has been put in by all parties. Thanks, David. David Rogers OMTP Director of External Relations The information contained in this e-mail and in any files transmitted with it is confidential and intended for the addressee only. If you are not the intended recipient(s) any distribution, copying or use of the information in this communication is prohibited and may be unlawful. If you have received this e-mail in error please notify the sender. This e-mail and any reply may be examined for purposes of reasonable supervision and monitored to ensure the maintenance of standards. This e-mail and any attachments have been scanned for viruses prior to leaving the sender's system but the sender will not be liable for any losses as a result of any viruses being passed on.
Re: [widgets] PC progression to CR
On Thu, Jul 16, 2009 at 1:36 PM, David Rogersdavid.rog...@omtp.org wrote: Art, Marcos, Please could you give us an update on the status of the progression of Widgets PC to CR? The editor's draft will be the one that is published (it is stable and ready to go, and has been for a few days): http://dev.w3.org/2006/waf/widgets/ I noticed on the publication status page this is still marked as LCWD. We would like to see prompt progression of this work given the level of effort that has been put in by all parties. Agreed. It's up to the W3C to gives us an publication date and set up the directors' call. We've done all we can as a WG I think. Not sure what the hold up is now. From past experience, even though this doc is done, my guesstimate is that the document will be published sometime in July (~3rd) at the earliest. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] PC progression to CR
On Thu, Jul 16, 2009 at 1:53 PM, Marcos Caceresmarc...@opera.com wrote: On Thu, Jul 16, 2009 at 1:36 PM, David Rogersdavid.rog...@omtp.org wrote: Art, Marcos, Please could you give us an update on the status of the progression of Widgets PC to CR? The editor's draft will be the one that is published (it is stable and ready to go, and has been for a few days): http://dev.w3.org/2006/waf/widgets/ I noticed on the publication status page this is still marked as LCWD. We would like to see prompt progression of this work given the level of effort that has been put in by all parties. Agreed. It's up to the W3C to gives us an publication date and set up the directors' call. We've done all we can as a WG I think. Not sure what the hold up is now. From past experience, even though this doc is done, my guesstimate is that the document will be published sometime in July (~3rd) at the earliest. I mean after August 3rd! (gee.. is it really July already?! :)) -- Marcos Caceres http://datadriven.com.au
RE: [widgets] PC progression to CR
Thanks Marcos, my comments below, marked [DAVID]: -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: 16 July 2009 12:53 To: David Rogers Cc: Arthur Barstow; Web Applications Working Group WG Subject: Re: [widgets] PC progression to CR On Thu, Jul 16, 2009 at 1:36 PM, David Rogersdavid.rog...@omtp.org wrote: Art, Marcos, Please could you give us an update on the status of the progression of Widgets PC to CR? The editor's draft will be the one that is published (it is stable and ready to go, and has been for a few days): http://dev.w3.org/2006/waf/widgets/ I noticed on the publication status page this is still marked as LCWD. We would like to see prompt progression of this work given the level of effort that has been put in by all parties. Agreed. It's up to the W3C to gives us an publication date and set up the directors' call. We've done all we can as a WG I think. Not sure what the hold up is now. From past experience, even though this doc is done, my guesstimate is that the document will be published sometime in July (~3rd) at the earliest. [DAVID] Thanks for clarifying on August 3rd. I think I express the entire group's sentiment by saying that we need to improve on this, at the very least to improve in the future for the remaining specs. I appreciate it is the holiday period but again, given the effort that has been put in and the foreknowledge that we were going to propose this as CR, how does it take nearly a month to get this through? -- Marcos Caceres http://datadriven.com.au
[WebStorage]
Hey folks, I have few questions on Web Storage Spec. I have checked the content of both latest published spechttp://www.w3.org/TR/webstorage/ and latest editors spechttp://dev.w3.org/html5/webstorage/. And the questions are applicable to both the versions of the spec. Section: 4.4.2 Processing model Text: 1. Open a new SQL transaction to the database, and create a SQLTransactionhttp://www.w3.org/TR/webstorage/#sqltransaction object that represents that transaction. If the mode is read/write, the transaction must have an exclusive write lock over the entire database. If the mode is read-only, the transaction must have a shared read lock over the entire database. The user agent should wait for an appropriate lock to be available. Concerns: - Why is the spec mandating a transaction to take an *exclusive write lock on the entire database*? No database book design mandates it. In fact, many client databases out there don't do this. I guess SQLite does this kind. But that does not mean that all implementations have this nature. I am kind of worried that we are putting implementation in theory. For me they are too separate, there are many ways a database could be designed. Like, log+checkpoint approach, shadow copy, version store, journals ...etc. I guess spec should say what a browser should do and not how. I would be happy to get enlightened. Thanks, Laxmi
[WebStorage] Concerns on spec section 'Processing Model'
[Adding the subject, sorry for spam!] Hey folks, I have few questions on Web Storage Spec. I have checked the content of both latest published spechttp://www.w3.org/TR/webstorage/ and latest editors spechttp://dev.w3.org/html5/webstorage/. And the questions are applicable to both the versions of the spec. Section: 4.4.2 Processing model Text: 1. Open a new SQL transaction to the database, and create a SQLTransactionhttp://www.w3.org/TR/webstorage/#sqltransaction object that represents that transaction. If the mode is read/write, the transaction must have an exclusive write lock over the entire database. If the mode is read-only, the transaction must have a shared read lock over the entire database. The user agent should wait for an appropriate lock to be available. Concerns: - Why is the spec mandating a transaction to take an *exclusive write lock on the entire database*? No database book design mandates it. In fact, many client databases out there don't do this. I guess SQLite does this kind. But that does not mean that all implementations have this nature. I am kind of worried that we are putting implementation in theory. For me they are too separate, there are many ways a database could be designed. Like, log+checkpoint approach, shadow copy, version store, journals ...etc. I guess spec should say what a browser should do and not how. I would be happy to get enlightened. Thanks, Laxmi
Re: Do we need to rename the Origin header?
Ian Hickson wrote on 7/15/2009 4:53 PM: On Wed, 15 Jul 2009, Bil Corry wrote: Ian Hickson wrote on 7/14/2009 6:37 PM: On Tue, 14 Jul 2009, Bil Corry wrote: Ian Hickson wrote on 7/14/2009 12:49 AM: (Trimmed cc list to avoid cross-posting.) On Thu, 25 Jun 2009, Bil Corry wrote: Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). I have no plans to add such a feature at this time, but I suppose if Sec-From becomes popular, we could add it at some future point, sure. The Sec-From draft relies on the adopter to define what constitutes privacy-sensitive -- will you be adding this definition to HTML5? HTML5 will say whatever Adam tells me it should say once the draft is stable. Given that identical requests may or may not be privacy-sensitive based entirely on context[1], and given that only the site itself understands the context, and given that HTML5 will not provide a way for the author to denote the context, we're left with Adam's default definition which may or may not be appropriate for any given request. We should revisit this once Adam has defined privacy-sensitive. I expect that what Adam will tell me to do is to make everything in HTML5 privacy-sensitive except GETs. I expect XHR GETs will not be. I think you mean everything will NOT be privacy-sensitive except non-XHR GETs. - Bil
WebDatabase/WebStorage (was Re: Points of order on this WG)
I would like to suggest that these specs be renamed to better reflect what they are about. For one, using the term Web in the title draws attention as the one (or the primary one). Secondly, it says nothing about the constructs offered. For example, WebDatabase suggests that this is *the* spec for structured storage, when, in fact, this group has argued in favor of multiple approaches, including one on B-tree databases that I have proposed. My suggestion is to rename the WebDatabase spec as the SQLDatabase spec. That way any other approach can be called the XXXDatabase spec. Similarly, with WebStorage, it is not clear what is the meaning of Web in the title, especially since we are currently left with just key-value storage. Since Web does nothing, except to distract and possibly mislead people into thinking that the spec covers all possible storage needs, I would suggest that the editor drop the word Web from the spec title. I also have a suggestion for the title - Key Value Storage. I do realize that this might be moot given that WebStorage has already gone through FPWD. Still, it does us no harm to at least rectify the situation now rather than going to CR with this name. Nikunj http://o-micron.blogspot.com On Jul 15, 2009, at 3:56 AM, Ian Hickson wrote: On Thu, 25 Jun 2009, Maciej Stachowiak wrote: On Jun 24, 2009, at 11:35 PM, Ian Hickson wrote: [...] (if anything, I think we should split Web Storage into two further specs [...] [...] I would prefer to see SQL Storage split out of the rest of Web Storage. We seem to have rough consensus and strong multilateral implementor interest on LocalStorage and SessionStorage, and they should be allowed to move forward on the standards track quickly. SQL Storage remains contentious, and only Apple and Google have shown strong implementor interest so far. And it has no technical tie to the other storage drafts. Done. http://dev.w3.org/html5/webstorage/ http://dev.w3.org/html5/webdatabase/ I'll probably not ask for Web Database to go to last call in October (unlike the rest of the specs I'm working on), so that we can add the SQL definition before last call (which I plan to do either Q4 this year or early next year). -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.'
Re: Do we need to rename the Origin header?
On Thu, Jul 16, 2009 at 8:47 AM, Bil Corryb...@corry.biz wrote: I think you mean everything will NOT be privacy-sensitive except non-XHR GETs. I don't think we've quite settled on exactly what will be privacy sensitive. It's most likely that POSTs and XHR will not be and that hyperlinks and image loads will be. The goal is to harmonize with the Mozilla proposal. Adam
Re: [WebStorage] Concerns on spec section 'Processing Model'
The spec should not restrict implementations to any one level of concurrency unless there are specific undesirable effects. Restricting the database to a single writer means that if there are separate workers or background threads working to update non- overlapping portions, then they have to wait for the lone current writer. Implementations can certainly compete to produce the level of concurrency that developers need. Specifically, I propose that the following text [[ If the mode is read/write, the transaction must have an exclusive write lock over the entire database. If the mode is read-only, the transaction must have a shared read lock over the entire database. The user agent should wait for an appropriate lock to be available. ]] be replaced with the following text [[ Multiple read-only transactions may share the same data as long as there is no transaction attempting to write the data being read. The user agent must wait for transactions that are reading some data before allowing a read/write transaction on the same data to continue. ]] Nikunj http://o-micron.blogspot.com On Jul 16, 2009, at 6:46 AM, Laxmi Narsimha Rao Oruganti wrote: [Adding the subject, sorry for spam!] Hey folks, I have few questions on Web Storage Spec. I have checked the content of both latest published spec and latest editors spec. And the questions are applicable to both the versions of the spec. Section: 4.4.2 Processing model Text: 1. Open a new SQL transaction to the database, and create a SQLTransaction object that represents that transaction. If the mode is read/write, the transaction must have an exclusive write lock over the entire database. If the mode is read-only, the transaction must have a shared read lock over the entire database. The user agent should wait for an appropriate lock to be available. Concerns: - Why is the spec mandating a transaction to take an *exclusive write lock on the entire database*? No database book design mandates it. In fact, many client databases out there don’t do this. I guess SQLite does this kind. But that does not mean that all implementations have this nature. I am kind of worried that we are putting implementation in theory. For me they are too separate, there are many ways a database could be designed. Like, log+checkpoint approach, shadow copy, version store, journals … etc. I guess spec should say what a browser should do and not how. I would be happy to get enlightened. Thanks, Laxmi
DataCache API - editor's draft available
I have published the first draft of the DataCache API, which is based on Oracle's BITSY proposal [1]. Here's a link to the draft: http://dev.w3.org/2006/webapi/DataCache/ This document defines APIs for dynamically and statically serving off-line representations of HTTP resources. As the Chairs have concluded this to be within the scope of our current charter, I would request feedback from you so we can incorporate it before publication as a working draft. Nikunj http://o-micron.blogspot.com [1] http://www.oracle.com/technology/tech/feeds/spec/bitsy.html [2] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0098.html
Re: WebIDL and prototype chains
On Thu, Jul 16, 2009 at 10:45 AM, Adam Barthw...@adambarth.com wrote: When a browser creates an instance of a DOM object defined by an WebIDL interface, the browser must choose where to connect it's prototype chain. For example, consider this case (where frames[0] is a same-origin child frame): var doc = frames[0].document; 1) To which global object's prototypes ought |doc| connect to, the parent frame running the script or the child frame from which we obtained the document? My best guess is that the prototype chain ought to connect to the child's prototype Absolutely. |doc| will simply be pointing to the same object that frames[0].document does. So the prototype chain must be the same for both. And it's clear that when code inside frames[0] accesses that frames document it should have a protochain based on the globals in that frame. I don't have any strong opinions on where this is specced. / Jonas
Re: WebDatabase/WebStorage (was Re: Points of order on this WG)
For what it's worth I don't think using the word Web in the name makes the connection that this is *the* *only* specification for storage for the web. I'll also point out that specs can be renamed at any point in the future if it turns out that the name is confusing. I also think the name of the spec is largely irrelevant. That said, I don't think a name like SQLDatabase is a very good name since there are lots of SQL database specifications and implementations. Something like WebSQLDatabase would be better. IMHO. But like I said, I think it's largely irrelevant. / Jonas On Thu, Jul 16, 2009 at 9:34 AM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: I would like to suggest that these specs be renamed to better reflect what they are about. For one, using the term Web in the title draws attention as the one (or the primary one). Secondly, it says nothing about the constructs offered. For example, WebDatabase suggests that this is *the* spec for structured storage, when, in fact, this group has argued in favor of multiple approaches, including one on B-tree databases that I have proposed. My suggestion is to rename the WebDatabase spec as the SQLDatabase spec. That way any other approach can be called the XXXDatabase spec. Similarly, with WebStorage, it is not clear what is the meaning of Web in the title, especially since we are currently left with just key-value storage. Since Web does nothing, except to distract and possibly mislead people into thinking that the spec covers all possible storage needs, I would suggest that the editor drop the word Web from the spec title. I also have a suggestion for the title - Key Value Storage. I do realize that this might be moot given that WebStorage has already gone through FPWD. Still, it does us no harm to at least rectify the situation now rather than going to CR with this name. Nikunj http://o-micron.blogspot.com On Jul 15, 2009, at 3:56 AM, Ian Hickson wrote: On Thu, 25 Jun 2009, Maciej Stachowiak wrote: On Jun 24, 2009, at 11:35 PM, Ian Hickson wrote: [...] (if anything, I think we should split Web Storage into two further specs [...] [...] I would prefer to see SQL Storage split out of the rest of Web Storage. We seem to have rough consensus and strong multilateral implementor interest on LocalStorage and SessionStorage, and they should be allowed to move forward on the standards track quickly. SQL Storage remains contentious, and only Apple and Google have shown strong implementor interest so far. And it has no technical tie to the other storage drafts. Done. http://dev.w3.org/html5/webstorage/ http://dev.w3.org/html5/webdatabase/ I'll probably not ask for Web Database to go to last call in October (unlike the rest of the specs I'm working on), so that we can add the SQL definition before last call (which I plan to do either Q4 this year or early next year). -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: WebDatabase/WebStorage (was Re: Points of order on this WG)
On Jul 16, 2009, at 1:18 PM, Jonas Sicking wrote: Something like WebSQLDatabase would be better. It may be irrelevant in the long run, but definitely worth a lot early on, IMHO. I like your name suggestion. Nikunj
Re: WebIDL and prototype chains
On Thu, Jul 16, 2009 at 1:13 PM, Jonas Sickingjo...@sicking.cc wrote: On Thu, Jul 16, 2009 at 10:45 AM, Adam Barthw...@adambarth.com wrote: When a browser creates an instance of a DOM object defined by an WebIDL interface, the browser must choose where to connect it's prototype chain. For example, consider this case (where frames[0] is a same-origin child frame): var doc = frames[0].document; 1) To which global object's prototypes ought |doc| connect to, the parent frame running the script or the child frame from which we obtained the document? My best guess is that the prototype chain ought to connect to the child's prototype Absolutely. |doc| will simply be pointing to the same object that frames[0].document does. So the prototype chain must be the same for both. And it's clear that when code inside frames[0] accesses that frames document it should have a protochain based on the globals in that frame. Firefox is much more consistent in this regard than Safari or Chrome: http://webblaze.org/abarth/tests/protoconfused/test1.html However, Firefox does not appear to attach function prototypes correctly. Maybe I should file a bug. :) Adam
Re: DataCache API - editor's draft available
Hi Nikunj, So one of the things I've never fully understood with your proposal is what usage patterns people are going to want to use this new API with. Is the idea that people that use XMLHttpRequest to load data from the server will in offline mode want to intercept those XHR requests and respond with data stored in for example localStorage or some other type of clientside storage? Without having to change the code that uses the XHR object? Or is the idea that for things like img src=... or script src=... people will in offline mode want to intercept these requests and serve replies based on data stored in localStorage/elsewhere? Or both? Or something else? / Jonas On Thu, Jul 16, 2009 at 1:10 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: I have published the first draft of the DataCache API, which is based on Oracle's BITSY proposal [1]. Here's a link to the draft: http://dev.w3.org/2006/webapi/DataCache/ This document defines APIs for dynamically and statically serving off-line representations of HTTP resources. As the Chairs have concluded this to be within the scope of our current charter, I would request feedback from you so we can incorporate it before publication as a working draft. Nikunj http://o-micron.blogspot.com [1] http://www.oracle.com/technology/tech/feeds/spec/bitsy.html [2] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0098.html
Re: WebIDL and prototype chains
On Thu, Jul 16, 2009 at 10:45 AM, Adam Barthw...@adambarth.com wrote: When a browser creates an instance of a DOM object defined by an WebIDL interface, the browser must choose where to connect it's prototype chain. Hopefully, we can spec the behavior non-DOM objects, like Array.prototype.push, and primitives converted to object, as well. Geoff
Re: WebIDL and prototype chains
On Thu, Jul 16, 2009 at 2:59 PM, Maciej Stachowiakm...@apple.com wrote: On Jul 16, 2009, at 10:45 AM, Adam Barth wrote: When a browser creates an instance of a DOM object defined by an WebIDL interface, the browser must choose where to connect it's prototype chain. For example, consider this case (where frames[0] is a same-origin child frame): var doc = frames[0].document; 1) To which global object's prototypes ought |doc| connect to, the parent frame running the script or the child frame from which we obtained the document? 2) Where is this behavior specified? If the behavior is currently not specified, which spec ought to contain the requirements? My best guess is that the prototype chain ought to connect to the child's prototype (because the document is owned by the child frame) and that the WebIDL spec ought to include this requirement (because WebIDL explains how to reify abstract DOM interfaces in ECMAScript). Thoughts? One thing to note: any object or method that is exposed cross-origin should specifically *not* have this behavior. Instead, it should create a separate interface object in every frame that accesses the property. window.history, window.location and window.postMessage are examples that require this treatment. Web IDL needs to give a hook to other specs so they can specify that cross-origin properties need to get this different treatment. I definitely agree you definitely don't want the inner windows prototype values if it's a cross-origin window. What you should get is less clear to me. If you should get the outer windows prototype or some sort of blank prototype. Personally it'd make the most sense to me if you got a blank prototype since that seems like the most consistent behavior. / Jonas
Re: DataCache API - editor's draft available
On Jul 16, 2009, at 2:43 PM, Jonas Sicking wrote: Hi Nikunj, So one of the things I've never fully understood with your proposal is what usage patterns people are going to want to use this new API with. Thanks for asking. Please ask me again if this response does not adequately address your needs. Is the idea that people that use XMLHttpRequest to load data from the server will in offline mode want to intercept those XHR requests and respond with data stored in for example localStorage or some other type of clientside storage? Without having to change the code that uses the XHR object? The client would continue to make the same calls during periods of network disruptions - this is why DataCache is transparent. However, instead of the response coming from the server, it would come from the DataCache. Whether to switch to using DataCache, or not, would be the browser's call - this is why DataCache is seamless. The browser can choose to switch depending on a variety of environmental or system conditions. In case where the client access data via XHR, the DataCache can produce either a static or a dynamic response. The static response does not involve any client side storage API - it is generated from the internal storage of DataCache as was populated when a resource was captured. The dynamic response is produced by some JavaScript code identified as the interceptor and it uses any state information accessible to the interceptor, including localStorage (or B-tree storage) and/or DataCache static responses. Or is the idea that for things like img src=... or script src=... people will in offline mode want to intercept these requests and serve replies based on data stored in localStorage/elsewhere? In the case where client access data via resource hyperlinks, e.g., a href=..., img src=... , object data=... or video src=..., the data could once again be serviced using static DataCache responses. Dynamic responses are also possible but less likely. In the case where client accesses data via form posts, through things such as form target=... either programmatically (i.e., form.submit) or not, the data could be servied using dynamic DataCache responses produced by an interceptor using the DataCache static responses and/or localStorage (or B-tree storage). All three cases would be equally well supported by DataCache API. The above processing approaches are the reason why DataCache and HTTP Interceptor are a single API and not two separate ones. Or both? Or something else? / Jonas On Thu, Jul 16, 2009 at 1:10 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: I have published the first draft of the DataCache API, which is based on Oracle's BITSY proposal [1]. Here's a link to the draft: http://dev.w3.org/2006/webapi/DataCache/ This document defines APIs for dynamically and statically serving off-line representations of HTTP resources. As the Chairs have concluded this to be within the scope of our current charter, I would request feedback from you so we can incorporate it before publication as a working draft. Nikunj http://o-micron.blogspot.com [1] http://www.oracle.com/technology/tech/feeds/spec/bitsy.html [2] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0098.html
Re: WebIDL and prototype chains
On Thu, Jul 16, 2009 at 2:58 PM, Jonas Sickingjo...@sicking.cc wrote: There's currently a bug in 3.5 which is why functions are failing. It is fixed in the upcoming 3.5.1 release. The only other non-PASS thing I see in firefox is .content, which basically is the same as .top and so is working as expected. This is a leftover from some old code which we should just remove. So no bug necessary :) Awesome. I've removed content from the test. Adam
Re: WebIDL and prototype chains
On Thu, Jul 16, 2009 at 3:08 PM, Jonas Sickingjo...@sicking.cc wrote: On Thu, Jul 16, 2009 at 2:59 PM, Maciej Stachowiakm...@apple.com wrote: One thing to note: any object or method that is exposed cross-origin should specifically *not* have this behavior. Instead, it should create a separate interface object in every frame that accesses the property. window.history, window.location and window.postMessage are examples that require this treatment. Web IDL needs to give a hook to other specs so they can specify that cross-origin properties need to get this different treatment. I definitely agree you definitely don't want the inner windows prototype values if it's a cross-origin window. What you should get is less clear to me. If you should get the outer windows prototype or some sort of blank prototype. Personally it'd make the most sense to me if you got a blank prototype since that seems like the most consistent behavior. Either behavior seems fine to me. I'd just like to see it speced somewhere so we can all do the same thing. :) Adam
RE: DataCache API - editor's draft available
On Thursday, July 16, 2009 2:43 PM, Jonas Sicking wrote: Hi Nikunj, So one of the things I've never fully understood with your proposal is what usage patterns people are going to want to use this new API with. [snip] / Jonas On Thu, Jul 16, 2009 at 1:10 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: I have published the first draft of the DataCache API, which is based on Oracle's BITSY proposal [1]. Here's a link to the draft: http://dev.w3.org/2006/webapi/DataCache/ Nikunj, thanks for putting together the document and publishing it. I agree with Jonas and I'd like to understand the expected use cases better too. I think I get the point that making the network access seamless regardless of whether there is network connectivity or not simplifies the network request code but seems to me to require more complex interception code. This isn't a pattern that I can readily map to customer requests we've received nor is it a familiar pattern to me personally. The other concern that I have is that this seems like an extension to the AppCache support in HTML 5. The new part is the ability to denote certain end-points that respond dynamically via script including supporting verbs other than GET. On the other hand, it appears to me that it proposes an entirely new programming model - did you consider an incremental approach that modifies window.applicationCache? Did you have particular reasons for rejecting that? Cheers, Adrian.
Re: DataCache API - editor's draft available
On Thu, Jul 16, 2009 at 3:13 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: On Jul 16, 2009, at 2:43 PM, Jonas Sicking wrote: Hi Nikunj, So one of the things I've never fully understood with your proposal is what usage patterns people are going to want to use this new API with. Thanks for asking. Please ask me again if this response does not adequately address your needs. Hi Nikunj, Starting over since I think you misunderstood my question. I do understand how Interceptor/DataCache works. And understand that it's seamless and can (based on a decision made by the browser) seamlessly intercept both XHR requests and img src=.. requests. What is not entirely clear to me is how you envision that authors will use it. I.e. are you expecting authors to want to intercept XHR requests? Or img src=... requests? Or script src=... requests? I understand that all of this is possible, but my question is what you expect people to do. I hope that makes sense? / Jonas
Re: DataCache API - editor's draft available
On Jul 16, 2009, at 3:54 PM, Jonas Sicking wrote: On Thu, Jul 16, 2009 at 3:13 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: On Jul 16, 2009, at 2:43 PM, Jonas Sicking wrote: Hi Nikunj, So one of the things I've never fully understood with your proposal is what usage patterns people are going to want to use this new API with. Thanks for asking. Please ask me again if this response does not adequately address your needs. Hi Nikunj, Starting over since I think you misunderstood my question. I do understand how Interceptor/DataCache works. And understand that it's seamless and can (based on a decision made by the browser) seamlessly intercept both XHR requests and img src=.. requests. What is not entirely clear to me is how you envision that authors will use it. Authors will use it in all three kinds of use cases I explained earlier - XHR, form, and hyperlinked data. DataCache is designed to support all three. The intention is to accommodate any use case arising from the issuance of a network request when the device is off- line. I.e. are you expecting authors to want to intercept XHR requests? For data driven applications, I expect this usage scenario. Or img src=... requests? Or script src=... requests? script src=... should be adequately supported by HTML5 (ApplicationCache), unless the src value is dynamic in nature. For the static case, I don't expect to see much usage of DataCache. I understand that all of this is possible, but my question is what you expect people to do. I hope that makes sense? / Jonas
Re: DataCache API - editor's draft available
Hi Adrian, I am glad to explain the use cases further as needed. I addressed Jonas' questions in separate messages, so I will focus here solely on your questions. Please see responses in-line. Nikunj http://o-micron.blogspot.com On Jul 16, 2009, at 3:31 PM, Adrian Bateman wrote: On Thursday, July 16, 2009 2:43 PM, Jonas Sicking wrote: Hi Nikunj, So one of the things I've never fully understood with your proposal is what usage patterns people are going to want to use this new API with. [snip] I agree with Jonas and I'd like to understand the expected use cases better too. I think I get the point that making the network access seamless regardless of whether there is network connectivity or not simplifies the network request code but seems to me to require more complex interception code. There is a tradeoff when adding the complexity of unreliable networks - either more complex client application code, or more complex client interception code. In our experience, we have found the latter to be actually more manageable for cases where the interception and off-line serving is done in a relatively application-independent manner. This isn't a pattern that I can readily map to customer requests we've received nor is it a familiar pattern to me personally. DataCache's interception pattern has existed for a while. A good survey of mobile data management and transaction support has covered this pattern [1]. The discussion there is not limited to Web browsers, though. Due to poor network coverage in the past, this pattern was not very valuable. However, as networks improve yet remain unpredictable, this pattern becomes more relevant. For example, if the network is 95% unavailable for 90% of the time (e.g., when one is out-of-office), then it makes sense to have a fully disconnected architecture. However, if the network is only 25% unavailable for 25% of the time, then it is better to have an architecture that fully utilizes server resources whenever possible and downshifts to an off-line scenario when needed. This is the pattern used in DataCache. The other concern that I have is that this seems like an extension to the AppCache support in HTML 5. The new part is the ability to denote certain end-points that respond dynamically via script including supporting verbs other than GET. Besides the verb difference, there are others that I have previously stated on this ML and blogged about [2]. I will summarize for your benefit. * ApplicationCache does not allow programmatic inclusion of items (dynamic entries were removed some time ago). all data capture in DataCache is through an API, i.e., as a dynamic entry. • ApplicationCache does not secure one user's private resources from another; DataCache requires the presence of a specified cookie • ApplicationCache uses its own data format for identifying items for local storage and exludes any other formats such as JSON and Atom; DataCache does not have any format limitations * ApplicationCache operates per its own refresh protocol and that excludes a different protocol, especially one that does not require all or nothing semantics for data versioning; DataCache has no protocol limitations. On the other hand, it appears to me that it proposes an entirely new programming model - did you consider an incremental approach that modifies window.applicationCache? Did you have particular reasons for rejecting that? Yes. I certainly considered window.applicationCache. I have previously proposed including additional things in HTML5, but the feedback was that the application cache could not be broken down in to any further primitives due to bootstrapping requirements [3]. I certainly feel that applicationCache can be composed with the primitives of DataCache + versioning. On the other hand, the converse is not possible due to ApplicationCache's: a. strictly static manifest serving, b. lack of support for version-free resources, and c. missing authorization checks. Cheers, Adrian. [1] http://portal.acm.org/citation.cfm?id=992378 [2] http://o-micron.blogspot.com/2009/04/how-is-bitsy-different-from-html-dojo.html [3] http://lists.w3.org/Archives/Public/public-html/2008Nov/0224.html
Re: WebIDL and prototype chains
On Jul 16, 2009, at 3:08 PM, Jonas Sicking wrote: I definitely agree you definitely don't want the inner windows prototype values if it's a cross-origin window. What you should get is less clear to me. If you should get the outer windows prototype or some sort of blank prototype. Personally it'd make the most sense to me if you got a blank prototype since that seems like the most consistent behavior. Window itself is even more of a special case. What I had in mind is objects hanging off of Window that are accessible to a limited extent cross-origin, such as History, or Location, or the postMessage function. I don't think it would work to give those a blank prototype. And you can't just give them the prototype chain from their home window because that would be an XSS violation. Regards, Maciej
Re: WebIDL and prototype chains
On Thu, 16 Jul 2009, Maciej Stachowiak wrote: On Jul 16, 2009, at 3:08 PM, Jonas Sicking wrote: I definitely agree you definitely don't want the inner windows prototype values if it's a cross-origin window. What you should get is less clear to me. If you should get the outer windows prototype or some sort of blank prototype. Personally it'd make the most sense to me if you got a blank prototype since that seems like the most consistent behavior. Window itself is even more of a special case. What I had in mind is objects hanging off of Window that are accessible to a limited extent cross-origin, such as History, or Location, or the postMessage function. I don't think it would work to give those a blank prototype. And you can't just give them the prototype chain from their home window because that would be an XSS violation. HTML5 just says that new History, Location, etc, objects are created for each (inner) Window object. Is this not accurate? What do browsers do? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Window Modes todo
Robin Berjon: To be honest, I'm not entirely certain of the value in enabling user script creation of these events — but I guess that's another matter. Sure. What concerns me is that all the initFooEvent/NS that we have all over are all copied and pasted from one another, and it's not entirely clear to me that this is not cargo-culting as I can't seem to recall what motivation there is for all of that :) Yeah it doesn’t seem particularly scalable. And what happens when we want to add another attribute on to the Event interface that we want to allow initialisation of? We won’t be able to just insert an argument in the middle of initUIEvent(), initMouseEvent(), etc. Having the attributes not be read only and allowing their modification before the Event is dispatched seems better to me. But changing this for DOM Events in general seems like a larger issue for discussion. -- Cameron McCormack ≝ http://mcc.id.au/
Re: WebIDL and prototype chains
On Jul 16, 2009, at 5:58 PM, Ian Hickson wrote: On Thu, 16 Jul 2009, Maciej Stachowiak wrote: On Jul 16, 2009, at 3:08 PM, Jonas Sicking wrote: I definitely agree you definitely don't want the inner windows prototype values if it's a cross-origin window. What you should get is less clear to me. If you should get the outer windows prototype or some sort of blank prototype. Personally it'd make the most sense to me if you got a blank prototype since that seems like the most consistent behavior. Window itself is even more of a special case. What I had in mind is objects hanging off of Window that are accessible to a limited extent cross-origin, such as History, or Location, or the postMessage function. I don't think it would work to give those a blank prototype. And you can't just give them the prototype chain from their home window because that would be an XSS violation. HTML5 just says that new History, Location, etc, objects are created for each (inner) Window object. Is this not accurate? What do browsers do? Creating new ones on navigation is indeed correct, but a separate issue from making sure cross-origin cross-frame access to things like history.back() is safe for both parties. Regards, Maciej
Re: WebIDL and prototype chains
On Thu, 16 Jul 2009, Maciej Stachowiak wrote: HTML5 just says that new History, Location, etc, objects are created for each (inner) Window object. Is this not accurate? What do browsers do? Creating new ones on navigation is indeed correct, but a separate issue from making sure cross-origin cross-frame access to things like history.back() is safe for both parties. In HTML5, you can't access .history cross-domain, and you can't get to the prototype of the .location object (the only thing you can do to .location is set the .href member). Are these restrictions Web-incompatible? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: WebIDL and prototype chains
On Jul 16, 2009, at 8:04 PM, Ian Hickson wrote: On Thu, 16 Jul 2009, Maciej Stachowiak wrote: HTML5 just says that new History, Location, etc, objects are created for each (inner) Window object. Is this not accurate? What do browsers do? Creating new ones on navigation is indeed correct, but a separate issue from making sure cross-origin cross-frame access to things like history.back() is safe for both parties. In HTML5, you can't access .history cross-domain, and you can't get to the prototype of the .location object (the only thing you can do to .location is set the .href member). Are these restrictions Web-incompatible? WebKit-based browsers allow cross-origin back(), forward() and go() on History, and replace(), reload() and assign() on Location, in addition to setting of href. I can't say definitively that all of those are needed to be Web compatible. Firefox allows access to at least location.replace() and history.back() cross-domain, and I would tentatively guess at least these two are required for Web compatibility. postMessage() (or, say, focus()) is another example of something that needs to be accessible cross-origin, and I don't think you can fully hide its prototype because call() and apply() should be usable on it, for example. I haven't thought through exactly how this needs to work. The point is mainly that anything accessible cross-origin probably can't just follow the normal rules for building a prototype chain. Regards, Maciej
