Re: [whatwg] BWTP for WebSocket transfer protocol
Thanks for the heads-up. This comes at an auspicious time, because we're now starting on WebSocket implementation in WebKit, and the implementation seems likely to someday ship in Safari, Chrome and other WebKit-based browsers. For what it's worth, we are not absolutely wedded to the details of either the API or the protocol, but we feel pretty strongly about delivering the basic functionality. This proposal looks a bit more complicated than the WS protocol, so it may take a bit to digest. Regards, Maciej On Aug 6, 2009, at 5:59 PM, Greg Wilkins wrote: All, on the IETF Hybi mailing list there has been some discussion regarding the protocol that should carry WebSockets. There was considerable divided opinions about the style of protocol that would be most appropriate and what level of features should be supported etc. That conversation ground to a stale mate as I think considerably different view points were involved. So it was decided by some to prepare an alternate transport protocol proposal. At the very least, this proposal would serve better illustrate many of the concerns and ideas that are difficult to express in long email threads. Hopefully, this proposal may influence the eventual design of the websocket proposal, or it might grow to become a real contender as an alternative (which currently it is not - lacking vital elements such as working implementations and wide peer review). Anyway, I'd like to invite the participants of this list to give the BWTP proposal some consideration and review: http://bwtp.wikidot.com I suggest reading the rational page http://bwtp.wikidot.com/main:rational first before looking at the proposal: http://bwtp.wikidot.com/main:proposal regards
Re: [whatwg] BWTP for WebSocket transfer protocol
Maciej Stachowiak wrote: This proposal looks a bit more complicated than the WS protocol, so it may take a bit to digest. Maciej, BWTP is indeed more complex that the base websocket protocol I think this is one of the key differences between the approach taken for the websocket protocol, which I think emphasises simplicity of implementation starting from scratch. But if your starting point is a working HTTP client or server, then the work needed to implement BWTP should not be too significant, as the additional complexities (Header fields and mime encoded content) are handle almost identically to HTTP. For what it's worth, we are not absolutely wedded to the details of either the API or the protocol, but we feel pretty strongly about delivering the basic functionality. I think everybody is keen on the basic functionality. But I think it is the non-basic reality that will ultimately drive the design of at least the protocol (if not the API). For example, when there are multiple WebSocket using components in the same frame/tab/browser - should they share TCP/IP connections to a host or should they multiplex. I see this as a trade off between additional complexity in the protocol for multiplexing vs consuming extra network/server resources for potentially many connections. Another example is compression. Currently websocket protocol supports only utf-8 or undefined binary framing.Over the life of HTTP, there was no compression, then there was compress and now gzip is widely supported. It could be expected that new compression algorithms will be developed over the life span of websocket and it will be important to be able to support them without the need to update the javascript that calls the websocket API. cheers
Re: [whatwg] HTML5: compatible with all legacy Web browsers
On Thu, 06 Aug 2009 19:49:45 +0200, Elliotte Rusty Harold elh...@ibiblio.org wrote: Section 1.7: The first such concrete syntax is HTML5. This is the format recommended for most authors. It is compatible with all legacy Web browsers. I challenge the claim that HTML5 is compatible with *all* legacy Web browsers. I guess it depends on the definition of compatible. I can produce valid HTML 4 documents today that are not compatible with *all* legacy Web browsers. That's irrelevant. Can you produce valid HTML5 documents today that are not compatible with all legacy Web browsers? I guess the following is an example of a valid HTML5 document that is incompatible with legacy Web browsers: !doctype html title/title svgscript//svg pHello world/p I suggest this be weakened to something like is compatible with most Web browsers still in active use today. What is it that is not compatible with which browser? -- Simon Pieters Opera Software
Re: [whatwg] HTML5: compatible with all legacy Web browsers
On Fri, Aug 7, 2009 at 5:39 AM, Simon Pieterssim...@opera.com wrote: What is it that is not compatible with which browser? Any use of legend outside of a fieldset is broken in every modern browser: IE6-8, Firefox 3-3.5, Safari 3-4, and Opera 9-10b all break in interesting ways. For more details, see Remy Sharp's Legend not such a legend anymore http://html5doctor.com/legend-not-such-a-legend-anymore/. Erik
[whatwg] small element should allow nested elements
Hi, I know Bruce Lawson has mentioned that this has been brought up before, but I couldn't find it in the archives (searching small), so I'd like to bring it up again. The HTML 5 spec says: Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements. http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-small-element So I'm making a list of disclaimers for my site: ol liYou must agree to this term/li liAnd this term too/li liAnd don't break this term/li liAnd don't forget the milk/li /ol pBy reading this, you're agreeing to xyz/p To make this valid, and small print text, I need to individually wrap the inner HTML of each inline element (li and p elements). This is wasteful and very much like the situation that we had with the a element when we wanted the whole block to be clickable. When I wrap *everything* in the small element (as seen here: http://jsbin.com/okevo ) all the browsers I've tested it in renders the text as I would expect, but it doesn't validate against the HTML 5 parsing rules (as you'd expect). If this element is truly for disclaimers, caveats and restrictions, and not stylistically making something small, then it will be typically used on blocks of content, be it a single line or multiple paragraphs. As such, it seems sensible to say that the small element can have nested block elements within it. Here's the list of the compatible browsers (I could have done more browsers, but I think this test with 10 proves the support is solid): http://leftlogic.litmusapp.com/pub/a5fa8ed smallAt time of writing, the last test is still being generated, but I've tested Firefox 3.5 manually and it passes/small ;-) Cheers, Remy Sharp Left Logic ___ I'm running a conference in Brighton on 20-Nov called: Full Frontal JavaScript Conference http://2009.full-frontal.org
Re: [whatwg] HTML5: compatible with all legacy Web browsers
I think the meaning of compatible with all existing browsers here is that HTML 5 does not *require* authors to break compatibility with any existing browser. Obviously some new features of HTML 5 will not work in some existing browsers -- otherwise there could be no new features in the spec! But it's designed to support graceful degradation wherever possible, so that authors can use many of the new features without breaking compatibility with any existing browser. This is in contrast to its erstwhile competitor XHTML 2 -- XHTML 2 cannot be used in any legacy browsers, ever. Clearer wording might be like, HTML5 pages can be written to be compatible with all legacy Web browsers. Of course, all legacy Web browsers does need to be construed to exclude Netscape Navigator 3 and such. If you really want to be picky, it could be all legacy Web browsers that still see significant use.
Re: [whatwg] HTML5: compatible with all legacy Web browsers
On Fri, Aug 7, 2009 at 8:28 AM, Aryeh Gregorsimetrical+...@gmail.com wrote: I think the meaning of compatible with all existing browsers here is that HTML 5 does not *require* authors to break compatibility with any existing browser. I agree completely with your interpretation of the phrase. HTML5 is intended to enhance the web without breaking it, so noting (or even emphasizing) how it's backwards-compatible is important and useful. But the phrase should be clarified along similar lines to what you've articulated. Maybe: HTML5 can be written in such a way that it is compatible with all browsers made after X date? Erik
Re: [whatwg] small element should allow nested elements
I should add, another argument for using small to wrap, is that without it, on a list element, the numerals in the list are larger than the the small print text - because the small element is on the inner HTML rather than the entire element (which does effect the numeric bullets too). Remy Sharp On 7 Aug 2009, at 14:19, Remy Sharp wrote: Hi, I know Bruce Lawson has mentioned that this has been brought up before, but I couldn't find it in the archives (searching small), so I'd like to bring it up again. The HTML 5 spec says: Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements. http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-small-element So I'm making a list of disclaimers for my site: ol liYou must agree to this term/li liAnd this term too/li liAnd don't break this term/li liAnd don't forget the milk/li /ol pBy reading this, you're agreeing to xyz/p To make this valid, and small print text, I need to individually wrap the inner HTML of each inline element (li and p elements). This is wasteful and very much like the situation that we had with the a element when we wanted the whole block to be clickable. When I wrap *everything* in the small element (as seen here: http://jsbin.com/okevo ) all the browsers I've tested it in renders the text as I would expect, but it doesn't validate against the HTML 5 parsing rules (as you'd expect). If this element is truly for disclaimers, caveats and restrictions, and not stylistically making something small, then it will be typically used on blocks of content, be it a single line or multiple paragraphs. As such, it seems sensible to say that the small element can have nested block elements within it. Here's the list of the compatible browsers (I could have done more browsers, but I think this test with 10 proves the support is solid): http://leftlogic.litmusapp.com/pub/a5fa8ed smallAt time of writing, the last test is still being generated, but I've tested Firefox 3.5 manually and it passes/small ;-) Cheers, Remy Sharp Left Logic ___ I'm running a conference in Brighton on 20-Nov called: Full Frontal JavaScript Conference http://2009.full-frontal.org
Re: [whatwg] DOMTokenList feedback
On Thu, Jul 30, 2009 at 6:38 PM, Ian Hicksoni...@hixie.ch wrote: On Mon, 27 Jul 2009, Jonas Sicking wrote: In general, I try to be as conservative as possible in making changes to the DOM. Are the algorithms really as complicated as you're making out? They seem pretty trivial to me. At least in the gecko implementation it's significantly more complex than not normalizing whitespace. The way that the implementation works in gecko is: When a class attribute is set, (during parsing or using setAttribute) we parse the classlist into a list of tokens. We additionally keep around the original string in order to preserve a correct DOM (actually, as an optimization, we only do this if needed). This token-list is then used during Selector matching and during getElementsByClassName. So far I would expect most implementations to match this. It would be very nice if DOMTokenList could be implemented as simply exposing this internal token list. With the recent change to not remove duplicates reading operations like .length and .item(n) maps directly to reading from this token list. All very nice. However writing operations such as .add and .remove requires operating on the string rather than the internal token-list. The current spec requires .remove to duplicate the tokenization process (granted, a pretty simple task) and modify the string while tokenizing. It would be significantly simpler if you could just modify the token-list as needed and then regenerate the string from the token-list. I've left it as is for now, but if other implementors agree that it would be significantly better to change it to normalise whitespace each time, I don't feel too strongly about it. I too am interested in feedback from other implementors. (We're agreed that removing would remove all duplicates, and that the order would be preserved, right?) Indeed. / Jonas
Re: [whatwg] BWTP for WebSocket transfer protocol
On Aug 7, 2009, at 12:25 AM, Greg Wilkins wrote: But if your starting point is a working HTTP client or server, then the work needed to implement BWTP should not be too significant, as the additional complexities (Header fields and mime encoded content) are handle almost identically to HTTP. From my review of the spec so far, it doesn't look like we'd be able to reuse much of our existing HTTP client implementation, at least not easily. The general header field parsing may be the same, but that code is trivial. The complex parts are the handling of specific headers, caching and connection management, and in most http libraries that code is not structured in a way that makes it easy to pick and choose. My tentative estimation is that the implementation effort for BWTP would be considerably higher. That's not to say it's a showstopper, it just means there is a tradeoff between additional functionality and implementation complexity. Regards, Maciej
[whatwg] RTSP in HTML5
Hi, I am not sure if this has already been discussed, but is there a plan to include RTSP protocol in HTML5 video tag in addition to HTTP? Thanks, Chytanya
Re: [whatwg] RTSP in HTML5
On Fri, 7 Aug 2009, Chytanya Karusala wrote: I am not sure if this has already been discussed, but is there a plan to include RTSP protocol in HTML5 video tag in addition to HTTP? In what sense do you mean include? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] RTSP in HTML5
I thought the video tag in HTML5 will point to a media resource which will be downloaded by the browser and passed on to the player engine inside the browser. If the src tag points to rtsp link the browser/player engine wouldn't know how to handle. By including the rtsp URI support in the video tag, player engine within every browser would act as a rtsp client making better streaming solutions possible (viz.. live streaming- in addition to download/progressive download already made possible by video tag) thanks Chytanya On Fri, Aug 7, 2009 at 1:01 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 7 Aug 2009, Chytanya Karusala wrote: I am not sure if this has already been discussed, but is there a plan to include RTSP protocol in HTML5 video tag in addition to HTTP? In what sense do you mean include? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] RTSP in HTML5
On Fri, 7 Aug 2009, Chytanya Karusala wrote: I thought the video tag in HTML5 will point to a media resource which will be downloaded by the browser and passed on to the player engine inside the browser. If the src tag points to rtsp link the browser/player engine wouldn't know how to handle. By including the rtsp URI support in the video tag, player engine within every browser would act as a rtsp client making better streaming solutions possible (viz.. live streaming- in addition to download/progressive download already made possible by video tag) Ah, I see. The HTML5 spec doesn't say what transports are expected to be supported; there's no reason browsers couldn't support RTSP as well as HTTP. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Microdata Revisited
On Mon, Aug 3, 2009 at 2:58 AM, Martin McEvoymar...@weborganics.co.uk wrote: Hello All I have been working on a new proposal for HTML 5 Microdata, I thought you might all like to take a look at what I have come up with so far. please visit http://weborganics.co.uk/test/microdata.html Any feed back would be nice ;) I'm in general vary of the use of prefixes here. Maciej summarized things very nicely in [1] / Jonas [1] http://lists.w3.org/Archives/Public/public-html/2009Jul/0919.html
Re: [whatwg] RTSP in HTML5
Thanks for the quick response! Browsers may not implement it unless it is mandated in the spec. Since browsers already have HTTP transport, I am afraid the browsers will end up just supporting HTTP as the only transport for the video tag. Since RTSP is the major streaming protocol and since HTML5 is supporting multimedia playback experience within the browser, including RTSP in the spec could completely do away with the need to have stand-alone RTSP clients installed or properitery plugins/solutions especially for live streaming. I think it makes everyone's life a lot easier knowing that there is a standard player engine present on every PC (through browser) that supports HTTP and RTSP in multimedia tags instead of worrying about the numerous proproeitery streaming protocols (based on HTTP) that are coming up with recently. Thanks, Chytanya On Fri, Aug 7, 2009 at 1:29 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 7 Aug 2009, Chytanya Karusala wrote: I thought the video tag in HTML5 will point to a media resource which will be downloaded by the browser and passed on to the player engine inside the browser. If the src tag points to rtsp link the browser/player engine wouldn't know how to handle. By including the rtsp URI support in the video tag, player engine within every browser would act as a rtsp client making better streaming solutions possible (viz.. live streaming- in addition to download/progressive download already made possible by video tag) Ah, I see. The HTML5 spec doesn't say what transports are expected to be supported; there's no reason browsers couldn't support RTSP as well as HTTP. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Web Workers and postMessage(): Questions
On Mon, Aug 3, 2009 at 4:14 PM, Robert O'Callahanrob...@ocallahan.org wrote: On Tue, Aug 4, 2009 at 5:34 AM, Daniel Gredler daniel.gred...@gmail.com wrote: I know Anne VK (Opera) and ROC (Mozilla) appear to read this list... any comments, guys? Should I just file bugs? Any Safari / Chrome / IE guys out there with comments? I know very little about these issues. Jonas Sicking reads this list and would know more. While I think dealing with cycles could be done, I agree with others that there are things of higher priority, like supporting ImageData or Files. What are the use cases for cyclic data? I'll note that neither JSON nor XML, which are also data-container formats, opted to allow for cycles. / Jonas
Re: [whatwg] RTSP in HTML5
On Fri, 7 Aug 2009, Chytanya Karusala wrote: Browsers may not implement it unless it is mandated in the spec. I assure you that what the spec says has little influence on what the browsers do. :-) I encourage you to contact the browser vendors directly if you would like to ensure that RTSP support is included in browsers. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Installed Apps
2009/7/30 Ian Fette (イアンフェッティ) ife...@google.com: That being said, I think there are valid use cases for out-of-band notifications, for example for calendar events or status update type applications such as Facebook or Twitter. I'd like to explore whether we can accommodate this notification use case without bringing the full power of the Web platform to bear, and thereby opening up a lot of attack surface on the client. Here's one rough sketch of an idea: * Notification Feeds * Often, web applications would like to give users the option to subscribe to notifications that occur at specific times or in response to server-side events, and for the user to get these UI notifications without a prerequisite that the web app is open or that the browser is running. There may be a desire to do client-side computation as well, but often just the ability to give the user a notification solves the basic user interaction problem. One possible way to address this kind of use case is to let users subscribe to a feed of notifications. This feed could use standard syndication formats, such as RSS or Atom. But instead of being displayed in a traditional feed reader, it's displayed in the form of transient notifications (along the lines of Growl on Mac OS X) which are posted for each new event. To allow some pre-scheduling of events, each item can have a date and won't be displayed until that date - this way a calendar can give you your feed of upcoming events and you can still get notifications when offline. In the case of something like email or Twitter, obviously there's no sensible way to get notifications when offline since they depend on unpredeictable server-side activity. There could even be a client-side API that lets a Web app schedule items on a subscribed notification feed from script, to enable scheduling calendar events offline. Each notification would have the option to unsubscribe from the notification feed, to reduce spam potential. Notice that this opens up a lot less attack surface. The user has to actively opt in to subscribing to the notification feed, just as for an RSS feed. This makes it much less likely they end up with a subscription to a shady site. And the notifications are passive data items (probably no script should be allowed in a notification, if the format is HTML and not just plain text), so they open up a lot less security risk. Obviously this is less powerful than the ability to run arbitrary code in the background. But it could address a large chunk of the use cases with much less security risk. It addresses some use cases (calendar, perhaps), but I would still like to be able to e.g. keep my email up to date. Do I need the full power / fully general solution? I don't know, perhaps the push mechanism can be structured in a way that it gets into my database or whatever storage mechanism I am using for offline data storage? I agree, however I don't think the solution is to allow a background webpage or something similar which has the full power of the web platform, and all the naughty things available to it. Instead I think it'd be great to have a protocol which allowed asynchronous updates to a client-side resource (or set of resources). There's nothing that would prevent this from happening over non-http protocols as well (such as SMS). / Jonas
Re: [whatwg] .tags on HTMLCollections
On Tue, Jul 28, 2009 at 2:48 PM, Ian Hicksoni...@hixie.ch wrote: On Mon, 13 Jul 2009, Boris Zbarsky wrote: Ian just pointed out to me that his current draft requires HTMLCollections to implement a tags() method (which seems to do a filter by tagName on the contents of the collection). As far as I can tell, IE, Webkit, and Opera implement this; Gecko does not. I was wondering whether any of the Webkit or Opera folks could comment on _why_ they implement this? I haven't seen any uses of this in the wild (outside document.all.tags, but document.all doesn't behave like a normal HTMLCollection in all sorts of other ways either). I'd rather be specifying (and implementing) a smaller DOM API, if that's all that's needed for actual web compat On Tue, 14 Jul 2009, Maciej Stachowiak wrote: Support for HTMLCollection.tags() in WebKit predates the fork from KHTML. So we don't know why it was originally added. On Tue, 14 Jul 2009, Boris Zbarsky wrote: I guess the other question is whether you feel it's worth keeping... On Tue, 14 Jul 2009, Maciej Stachowiak wrote: I don't know of a reason it's needed for collections other than document.all. But it also doesn't seem harmful and I can't say definitively whether it helps anything. I wouldn't object to removing it from the spec, but we probably wouldn't remove it from WebKit short of evidence that it's actually harmful. Perhaps Opera people can shed more light on the matter. On Thu, 23 Jul 2009, Anne van Kesteren wrote: From what I heard so far it is there because of document.all. If document.all does indeed need to return a separate object as HTML5 suggests we can probably remove it from HTMLCollection in due course. I haven't removed HTMLCollection.tags yet, since it appears to be implemented by most browsers. If we can get Opera and WebKit to remove support, then I'll remove it from the spec. Given that we have some data indicating that .tags() is not needed for web compatibility (Firefox doesn't support it and has received no requests for it, or bugs indicating sites needing it), and so far only weak data indicating it is needed (UAs support it, but not clear why), why not leave it out of the spec for now? UAs are always free to continue supporting it if they so please. I have very little desire to add support for anything to gecko just in case, without any data indicating anyone would use it, much less needs it. / Jonas
Re: [whatwg] BWTP for WebSocket transfer protocol
Maciej Stachowiak wrote: On Aug 7, 2009, at 12:25 AM, Greg Wilkins wrote: But if your starting point is a working HTTP client or server, then the work needed to implement BWTP should not be too significant, as the additional complexities (Header fields and mime encoded content) are handle almost identically to HTTP. From my review of the spec so far, it doesn't look like we'd be able to reuse much of our existing HTTP client implementation, at least not easily. The general header field parsing may be the same, but that code is trivial. The complex parts are the handling of specific headers, caching and connection management, and in most http libraries that code is not structured in a way that makes it easy to pick and choose. My tentative estimation is that the implementation effort for BWTP would be considerably higher. That's not to say it's a showstopper, it just means there is a tradeoff between additional functionality and implementation complexity. Maceij, That's valuable feedback. My experience is mostly the server side and I think when it comes to connection handling the server has an easier time of it than the client - so I can see that BWTP would have more of an impact on the client. Remember, at this stage BWTP is a thought experiment, so it is definitely easy to adapt to new ideas or drop features that are too complex for the benefit they give. So are there any changes or omissions that you can suggest that would make a client implementation easier? For example, I proposed the default header mechanism to address concerns Ian expressed about per message byte count.However, this is not something that HTTP does (and we get by with hundreds of bytes per request), so perhaps we could leave out the default Header mechanism at the price of more bytes per message? Also there is the possibility of making features like multiplexing optional and negotiated. This would allow simple non-multiplexing implementations, but might cause additional complexity in negotiation. That really comes down to how important people think multiplexing is. I think that it is moderately important because I can imagine pages with 10s of individual widgets, each opening a websocket, so my server will be looking at 10x the number of connections per user. If users open multiple windows, then it's 20x! On the server, connections are pretty cheap, but not that cheap. cheers
Re: [whatwg] BWTP for WebSocket transfer protocol
On Fri, Aug 7, 2009 at 12:25 AM, Greg Wilkinsgr...@mortbay.com wrote: Maciej Stachowiak wrote: This proposal looks a bit more complicated than the WS protocol, so it may take a bit to digest. Maciej, BWTP is indeed more complex that the base websocket protocol I think this is one of the key differences between the approach taken for the websocket protocol, which I think emphasises simplicity of implementation starting from scratch. But if your starting point is a working HTTP client or server, then the work needed to implement BWTP should not be too significant, as the additional complexities (Header fields and mime encoded content) are handle almost identically to HTTP. cc'ing Wellington who has written a websocket implementation for Firefox. Would be great to get his feedback for what savings could be done if we were to use BWTP as transport protocol compared to using websocket. My impression is like Maciejs, that we wouldn't be able to reuse much of our current HTTP infrastructure in order to implement BWTP. At first glance only the header-parsing code would carry over directly, but that's not many lines of code and so doesn't seem like a big win. For what it's worth, we are not absolutely wedded to the details of either the API or the protocol, but we feel pretty strongly about delivering the basic functionality. I think everybody is keen on the basic functionality. But I think it is the non-basic reality that will ultimately drive the design of at least the protocol (if not the API). For example, when there are multiple WebSocket using components in the same frame/tab/browser - should they share TCP/IP connections to a host or should they multiplex. I see this as a trade off between additional complexity in the protocol for multiplexing vs consuming extra network/server resources for potentially many connections. Another example is compression. Currently websocket protocol supports only utf-8 or undefined binary framing. Over the life of HTTP, there was no compression, then there was compress and now gzip is widely supported. It could be expected that new compression algorithms will be developed over the life span of websocket and it will be important to be able to support them without the need to update the javascript that calls the websocket API. I agree that these are very interesting features. Especially connection multiplexing is something that I think is a good idea, for the reasons you've mentioned elsewhere in this thread (multiple widgets on the same page). But even compression is nice if it was possible. My gut feeling on BWTP vs. websocket is that BWTP carries some unneccesary complexity/overhead by allowing arbitrary headers in each frame, whereas websocket is unnecessarily low level. I don't think BWTP gains a lot by using HTTP-like syntax, as I don't think that in reality a lot of existing HTTP code can be reused. / Jonas
Re: [whatwg] Installed Apps
From: Jonas Sicking jo...@sicking.cc Sent: Friday, August 07, 2009 5:07 PM 2009/7/30 Ian Fette ife...@google.com: That being said, I think there are valid use cases for out-of-band notifications, for example for calendar events or status update type applications such as Facebook or Twitter. I'd like to explore whether we can accommodate this notification use case without bringing the full power of the Web platform to bear, and thereby opening up a lot of attack surface on the client. Here's one rough sketch of an idea: * Notification Feeds * Often, web applications would like to give users the option to subscribe to notifications that occur at specific times or in response to server-side events, and for the user to get these UI notifications without a prerequisite that the web app is open or that the browser is running. There may be a desire to do client-side computation as well, but often just the ability to give the user a notification solves the basic user interaction problem. One possible way to address this kind of use case is to let users subscribe to a feed of notifications. This feed could use standard syndication formats, such as RSS or Atom. But instead of being displayed in a traditional feed reader, it's displayed in the form of transient notifications (along the lines of Growl on Mac OS X) which are posted for each new event. To allow some pre-scheduling of events, each item can have a date and won't be displayed until that date - this way a calendar can give you your feed of upcoming events and you can still get notifications when offline. In the case of something like email or Twitter, obviously there's no sensible way to get notifications when offline since they depend on unpredeictable server-side activity. There could even be a client-side API that lets a Web app schedule items on a subscribed notification feed from script, to enable scheduling calendar events offline. Each notification would have the option to unsubscribe from the notification feed, to reduce spam potential. Notice that this opens up a lot less attack surface. The user has to actively opt in to subscribing to the notification feed, just as for an RSS feed. This makes it much less likely they end up with a subscription to a shady site. And the notifications are passive data items (probably no script should be allowed in a notification, if the format is HTML and not just plain text), so they open up a lot less security risk. Obviously this is less powerful than the ability to run arbitrary code in the background. But it could address a large chunk of the use cases with much less security risk. It addresses some use cases (calendar, perhaps), but I would still like to be able to e.g. keep my email up to date. Do I need the full power / fully general solution? I don't know, perhaps the push mechanism can be structured in a way that it gets into my database or whatever storage mechanism I am using for offline data storage? For the purpose of notification, it seems we have the following solutions: -Push message -SMS -RSS/Atom feed -Polling (Probably through JavaScript) Which will manifest in the following types of program: -Hidden browser page, Standalone browser tab, Persistent worker, or the browser's main background process, as part of the browser -Extraneous app or device (SMS to phone, or small-footprint desktop feed-reader) Any others you can add to those lists? (You can read the rest, or visit the summary near the bottom.) To go through the methods: RSS/Atom is usable at this very moment, as is JavaScript polling and SMS. SMS can be expensive, but Twitter has proven how useful it can be. I'm not sure what applications support push messages. Deciding where the messages appear is the tricky part: A low-footprint, invisible feed-reader app can be run in the background and pop up messages when they're received. This will require users to install third-party tools, which could integrate themselves with the browsers to open links or manage 'feeds'. Phones could be used to handle SMS notifications or push messages. The browsers could check for updates in a tab, but there are a couple things that need to change before this becomes feasible: 1) Browsers need to be able to pop up a notification in the corner, possibly with a link that sets focus to the notifying tab, 2) Browsers need to get the notifying tab out of the way, either by shrinking it to a notification area or by running it as a background process (where it can be accessed from the browser through some sort of Application Manager), and 3) Hidden tabs need to continue to run when the browser is closed (i.e. the browser's main process continues to run) until the hidden page is exited. It sounds like the browser could have a small background process that manages notifications, and a webapp (such as Gmail) could register with the browser's notification process. That could be separate from the idea of
Re: [whatwg] BWTP for WebSocket transfer protocol
Jonas, taking some of your comments out of order My gut feeling on BWTP vs. websocket is that BWTP carries some unneccesary complexity/overhead by allowing arbitrary headers in each frame, whereas websocket is unnecessarily low level. I added the headers to BWTP (headers), because I didn't like the total lack of meta data in websocket.I then added virtual connections afterwards. But now you mention it, arbitrary headers in each frame is probably excessive since it could be argued that all the messages to/from a given URI are likely to have mostly same metadata so perhaps a protocol that supports virtual connections does not need per message meta data. So maybe metadata per virtual connection meta-data is sufficient? I don't think BWTP gains a lot by using HTTP-like syntax, as I don't think that in reality a lot of existing HTTP code can be reused. I don't think HTTP-like syntax is essential. I was just using it to start from a familiar place. It is the features that BWTP has that Websocket lacks that I think are important (plus I admit a total dislike of 0 delimited framing :). I agree that these are very interesting features. Especially connection multiplexing is something that I think is a good idea, for the reasons you've mentioned elsewhere in this thread (multiple widgets on the same page). But even compression is nice if it was possible. Indeed it is the features that are more important ideas in BWTP rather than the syntax of the protocol. The features that I feel are important to have in the protocol are: + mime encapsulated content types (not just utf-8 and binary). + extensible content-encoding and/or transfer encoding + multiplexing + orderly close Nice to have features include: + message segmentation (good for flow when multiplexing). + intermediary participation + strict in what you generate, forgiving in what you parse + BNF style specification rather than algorithmic specification. + per message meta data My impression is like Maciejs, that we wouldn't be able to reuse much of our current HTTP infrastructure in order to implement BWTP. At first glance only the header-parsing code would carry over directly, but that's not many lines of code and so doesn't seem like a big win. Again this is valuable feedback. That's three -0' or -1's on the look-a-like-HTTP approach. I'll ponder what sort of simplifications could be made if the HTTP style is dropped. cheers
