Re: [hybi] [Fwd: Comments on draft-hixie-thewebsocketprotocol-35]

[Graham Klyne <[e-mail]>]

Greg,

[Julian kindly forwarded my comments to this list, as I have been having trouble 
getting messages through (maybe it will work this time)).]

Your comments about viewing this specification as a requirements document is 
fair enough, except that I have no idea from reading the document what 
requirements it is trying to address.  But I do agree it would be helpful to 
have an articulated set of requirements and problems to be avoided to assist 
evaluations.

Although I mentioned BEEP as an example, I can also see why it would be a hard 
candidate to sell.  It seems to me that easy browser-side implementation using 
Javascript would be a requirement, and my intuition is that BEEP requires quite 
a lot of state management that might make a solid browser implementation hard to 
achieve.

BTW, while candidates are being tossed around, I have done some implementation 
work in this area that is entirely open source.  I know it has many 
shortcomings.  The project is at http://code.google.com/p/webbrick-events/.  The 
main use-case for this was using a browser as a real-time control and monitoring 
interface for home automation, etc., which I think is rather like a presence 
protocol. I have aimed for the simplest content model that would support the 
protocol requirements, which is described at 
http://code.google.com/p/webbrick-events/wiki/EventModel.  Mainly, I think that 
if a requirements document were being assembled, I might be able to fillet out 
some thoughts to contribute.

FWIW, my favourite candidate to date is BOSH, mainly as it focuses on protocol 
requirements without imposing much content model, *and* that it works over 
unmodified HTTP.  But I haven't properly reviewed the alternatives.

I took a quick look at your BWTP and my immediate off-the-cuff thoughts are:
  * the spec seems quite easy to read and follow :)
  * it doesn't really indicate the requirements or use-cases it aims to satisfy 
(but it does say that it's intended to provide bi-directional transfers, so 
maybe that's enough, though I'd like to see asynchronous delivery to the client 
explained).
  * I'm not sure that there's an easy migration path from unenhanced HTTP for 
applications that need bidirectional data capabilities.  For example, I'd need 
to think a lot harder than I have time for right now to decide if this could be 
implemented using Javascript in a browser.

Cheers,

#g
--

Greg Wilkins wrote:
> Julian Reschke wrote:
> 
>> I think the specification, in its current form, completely fails to present
>> itself as such a solution.  To me, it reads less like an open protocol
>> specification, and rather more like a programming team internal design
>> memo.
> 
> Julian,
> 
> I too have been very critical of the websocket protocol.
> But I think that the IETF and specifically the hybi group should not
> get become "captured" by trying to correct short comings of this
> protocol and it's specification.   It is very difficult to critique
> the protocol and/or proposal as the authors find it very suitable for
> their specific purposes.
> 
> Instead, I believe that the websocket protocol should be viewed as just
> one  use-case for a bidirectional protocol coming from the whatwg efforts
> on HTML5.  I think it should consider it more of a requirements document
> than a real proposal for an open protocol specification.
> 
> If the IETF were to move forward on a real open protocol specification that
> met the use-case of the websocket proposal (among others), then surely
> all parties would be content with the result.
> 
> 
> 
>> but I find myself asking:  why not just specify a hand-off extension to
>> HTTP
>> that allows bidirectional communication to proceed using a protocol such as
>> BEEP?  I fear there's a certain amount of reinvention going on here.  But I
>> could be wrong.
> 
> I previously advocated BEEP as a possible protocol for the bidirection web.
> See the thread "Is there a traffic jam?" in the hybi list, which briefly
> discussed BEEP before going off topic.
> 
> The argument that eventually convinced me that BEEP was not entirely
> suitable, was that while BEEP framing is simple and suitable, the channel
> management of BEEP is rather complex and requires XML.
> 
> 
> So I draw your attention again to the BWTP draft proposals.  The first
> of these http://bwtp.wikidot.com/main:proposal, was very much influenced
> by HTTP - but the feedback received was that it too was a bit too complex
> for the features that it provided.
> 
> The second BWTP proposal: http://bwtp.wikidot.com/main:proposal1 is modeled
> more off BEEP than HTTP.   I believe it provides a rich bidirectional
> feature set, which maintaining the simplicity of BEEP style framing.
> 
> 
> But even if you find BWTP inappropriate, I believe that the IETF
> should be working from known successful protocols and protocol
> experience to design, test and specify an new bidirectional protocol.
> 
> Surely the IETF should build from it's existing knowledge base
> rather than adopt a binary protocol proposal for a very
> specific purpose that is a radical departure from the style
> and substance of past IETF protocols!
> 
> 
> cheers
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>