Re: [websockets] What needs to be done before the spec is LC ready?
On Tue, 5 Apr 2011, Arthur Barstow wrote: What needs to be done before the WebSocket API is LC ready? I'm currently waiting for a number of editorial changes to the protocol specification to provide hooks for the API specification so that I can update the API apecification to work with the new protocol. 3. The definition of absolute url makes https:foo not an absolute url, since its behavior depends on whether the base is https: or not. Is that desired? ... http://www.w3.org/Bugs/Public/show_bug.cgi?id=10213 This particular bug is blocked on there being a specification that defines how URLs work. Last I heard, Adam was going to be writing it. I would also be unblocked if the IRI work at the IETF were to actually happen (it was supposed to happen about 2 years ago now). There was a also a recent HTML WG decision to put the requirements into the HTML spec. The decision starts with text that is known to be broken and so also requires editing work; however, it's possible that I'll end up updating that before Adam's work is done, in which case I'll use that instead. Either way this particular bug isn't likely to be fixed in a hurry. In practice it's not a huge blocker; in fact I'm not sure it's a blocker at all, as it is possible that the WebSocket protocol spec now defines how this issue is handled anyway, in which case the bug won't actually block the API spec. I'll find out when the edits to the protocol spec are done and I get to update the API spec for the new protocol spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [websockets] What needs to be done before the spec is LC ready?
There's also potentially protocol changes that will cause use to need to fix things at the API layer. For example, if the IETF introduces redirects into the protocol, we'll likely need to account for them at the API layer: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-March/031070.html Adam On Tue, Apr 5, 2011 at 10:15 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 5 Apr 2011, Arthur Barstow wrote: What needs to be done before the WebSocket API is LC ready? I'm currently waiting for a number of editorial changes to the protocol specification to provide hooks for the API specification so that I can update the API apecification to work with the new protocol. 3. The definition of absolute url makes https:foo not an absolute url, since its behavior depends on whether the base is https: or not. Is that desired? ... http://www.w3.org/Bugs/Public/show_bug.cgi?id=10213 This particular bug is blocked on there being a specification that defines how URLs work. Last I heard, Adam was going to be writing it. I would also be unblocked if the IRI work at the IETF were to actually happen (it was supposed to happen about 2 years ago now). There was a also a recent HTML WG decision to put the requirements into the HTML spec. The decision starts with text that is known to be broken and so also requires editing work; however, it's possible that I'll end up updating that before Adam's work is done, in which case I'll use that instead. Either way this particular bug isn't likely to be fixed in a hurry. In practice it's not a huge blocker; in fact I'm not sure it's a blocker at all, as it is possible that the WebSocket protocol spec now defines how this issue is handled anyway, in which case the bug won't actually block the API spec. I'll find out when the edits to the protocol spec are done and I get to update the API spec for the new protocol spec. -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [websockets] What needs to be done before the spec is LC ready?
On Tue, 5 Apr 2011, Adam Barth wrote: There's also potentially protocol changes that will cause use to need to fix things at the API layer. For example, if the IETF introduces redirects into the protocol, we'll likely need to account for them at the API layer: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-March/031070.html Yeah, there's always the chance that the protocol will require further changes, indeed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: [websockets] What needs to be done before the spec is LC ready?
On Tuesday, April 05, 2011 4:27 AM, Arthur Barstow wrote: Hi All, What needs to be done before the WebSocket API is LC ready? Bugzilla has three open bugs for this spec: 1. API for send/receive of binary data? Current IETF protocol drafts have binary type. Consider typed arrays (ArrayBuffer). http://www.w3.org/Bugs/Public/show_bug.cgi?id=11834 2. WebSocket protocol update time http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102 3. The definition of absolute url makes https:foo not an absolute url, since its behavior depends on whether the base is https: or not. Is that desired? ... http://www.w3.org/Bugs/Public/show_bug.cgi?id=10213 We've made some proposals in the 12102 bug based on our prototyping with this API. As we work through this I expect we'll also have feedback on areas we think need additional detail to ensure interoperability by different implementers. I've included our recent feedback below, quoted from the bug. Adrian. http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102 There are use cases for both Blob and ArrayBuffer. While it's possible to convert between the two it's also convenient to be able to specify the preferred type just like with XHR, which supports both. Supporting both would require a mechanism to specify the preferred type. In fact, as we've been experimenting with the WebSocket API we've found that initiating network I/O from the constructor is somewhat inconvenient. We would much prefer a model more like XHR and feel that this is better for future extensibility as the API develops. Our proposal to start the discussion: * The constructor behavior and signature is changed to follow the XHR model. It instantiates a WebSocket object but does not establish the connection. * A new ready state constant is added to indicate that a WebSocket has been created, but no connection established. * A new open method is added to the API to establish the connection: void open(in DOMString url); * A supportedProtocols attribute is added. This is the list of protocols sent by the client to the server during the handshake. This replaces the protocols parameter in the current constructor. attribute DOMString[] supportedProtocols; * Add overloads to send void send(in Blob data); void send(in ArrayBuffer data); * A binaryResponseType attribute is added to the WebSockets interface which can be set to: arraybuffer or blob. The default string might default to ArrayBuffer or it might indicate that the client isn't expecting binary data. We'd like to discuss this more. attribute DOMString binaryResponseType; * Message event event.data returns a string for text messages and the type specified in binaryResponseType for binary data. Message event only fires when the entire message is available.
RE: [WebSQL] Any future plans, or has IndexedDB replaced WebSQL?
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Keean Schupke Sent: Monday, April 04, 2011 10:17 PM Something like RelationalDB gives you the power of a relational-db with no dependence on a specific implementation of SQL, so it would be compatible enough for the web. It fixes all the problems with the standardisation of WebSQL that have been talked about so far. I think it would find no technical issues that block its standardisation. As a high level DB API it does not need all the low-level features of IndexedDB, so its API can be much simpler and cleaner. RelationalDB can at least be provided as a library on top of IndexedDB, and it can use WebSQL where it is supported. My concern with the library approach is performance when implemented on top of IndexedDB. The goal of IndexedDB has always been to enable things like RelationalDB and CouchDB to be built on top, while maintaining a reasonable level of functionality for those that wanted to use it directly. I really like the idea of thinking of RelationalDB as something that's built as a library on top of IndexedDB. Are there specific tweaks we can make to IndexedDB so it can be a good lower-layer for RelationalDB, such that RelationalDB could be built as a pure JavaScript library? Thanks -pablo
Re: [WebSQL] Any future plans, or has IndexedDB replaced WebSQL?
On 06 Apr 2011, at 2:53 AM, Pablo Castro wrote: The goal of IndexedDB has always been to enable things like RelationalDB and CouchDB to be built on top, while maintaining a reasonable level of functionality for those that wanted to use it directly. I really like the idea of thinking of RelationalDB as something that's built as a library on top of IndexedDB. Are there specific tweaks we can make to IndexedDB so it can be a good lower-layer for RelationalDB, such that RelationalDB could be built as a pure JavaScript library? Thanks -pablo 1. Treat object values as opaque (necessary to avoid deserialization/serialization overhead, this is mandatory for storing anything over 50,000 objects on a device like an iPad or iPhone). 2. Enable indices to be modified at time of putting/deleting objects (index references provided by application at time of putObject/deleteObject call). 3. Provide a simpler, more powerful locking mechanism, opaque to IndexedDB, to provide finer-grained application-specific locking (i.e. have we just entered into a sync process with the master database). If I may say so, it does seem odd that some would advocate the difficulties of speccing merely the interface of something like SQLite, and then advise others to suggest re-implementing it entirely. If there was a specific BTree API in the browser and a powerful asynchronous sLocalStorage mechanism this might be something for the brave, but IndexedDB is a little too tightly coupled to it's own interface agenda at the moment to make this goal possible.
Re: RfC: WebApps Testing Process
On 4/4/11, Garrett Smith dhtmlkitc...@gmail.com wrote: On 4/4/11, James Graham jgra...@opera.com wrote: (setting followup to public-testinfra) On 04/04/2011 01:45 AM, Garrett Smith wrote: I'd rather see the `format_value` function broken up. It makes non-standard expectations of host objects (`val`) and that there is a global `Node` object. Which standard requires that? Well Web DOM Core does. I assume DOM Core 2 also does but I'm not sure where the IDL variant it uses is specified. I looked but I didn't see it where the spec says there's a global `Node`. Looked again. Still don't see it. Can anyone provide a fragment URI or cite the part of the spec that defines a global `Node`? -- Garrett
