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

[Salvatore Loreto <[e-mail]>]

Hi Graham,

as a first tentative to put some order in the discussion about how to 
"PUSH" information to a client and/or browser application,
we have write down a draft that focuses on best practices for 
bidirectional HTTP in the context of HTTP as it exists today.
The document envisions also possible additions to HTTP that could enable 
improved mechanisms for bidirectional HTTP
(for what we call, the short term solution to the bidirectional 
communication, where the long term is supposed to be something
like WebSocket or BWTP)

here the link: http://www.ietf.org/id/draft-loreto-http-bidirectional-00.txt

it would great if you have time to review it and provide 
comments/suggestions.

Moreover as we are now working on a new version where we are trying to 
more clearly describe the design space, including
the programming environments (client, server, library, etc.), deployed 
infrastructure (routers, proxies, etc.).
Any help coming from your implementation experience is welcome.

cheers
Sal

www.sloreto.com


Graham Klyne wrote:
> 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
>>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi