Re: [hybi] Random Responses

[rektide <[e-mail]>]

On Thu, Apr 09, 2009 at 09:06:23AM -0700, Mark Lentczner wrote:
>
> On Apr 8, 2009, at 5:34 PM, Ian Hickson wrote:
>> I misspoke, I should have said that the point of full-duplex  
>> communication
>> is that it's not request-response -- either side can spontaneously  
>> send a
>> message.
>
> Then I mis-replied. I should have said that we have a need for full- 
> duplex request-response -- either side can spontaneously send a request 
> message, and either side can, when ready, reply to a prior request.

I'd inject that a "worthy" transport also has to be able to permit either side to ad-hoc
initiate communication at any time as well.  I'd also say either end must be able to opt to
never reply without violating the transport spec.

How the reader dices this is anyone's guess: is this is a request-response transport with
optional reply, or is this a event transport with optional request-reply? I dont think it
matters, I think a good transport ought to support both.

>> The socket in WebSocket can be (indeed, must be) addressed via URL.
>
> Only the establishment in WebSocket is addressed via URL.  In rHTTP each 
> request can be addressed by URL.  This is useful as it is a very common 
> piece of meta-data that applications want. For example, using  
> WebSockets, for any complex page, an application is almost certainly  
> going to want a way to address which widget on the page is the intended 
> recipient of the event. Hence, each application is going to have to 
> devise an addressing scheme, and more importantly, a method of encoding 
> that address in the simple string event.

Addressability to the client side is something I had not considered before.  I would be very
interested to hear how this would work in a collaborative environment, how the server would
deal with multiple clients.

When I was heavily investigating Bayeux, I often thought each client should have a service
channel to enable cross system addressability.  I never had a concrete API sketched out for
how the endpoint would function, just the notion that there would be a URL template for
talking to clients.

>> At the message level, why do we need to force those features on all  
>> users?
>> They seem like features we should allow people to have if they want,  
>> but
>> they don't seem like features we should require all clients and  
>> servers to
>> implement just because someone might want them.
>
> Of course, but you must recognize there is a trade-off here that all  
> protocols make. The design needs to choose a feature set wide enough  
> that many different applications can make use of it, but must do so  
> balancing complexity and overhead. For example, WebSockets has chosen to 
> support both binary and UTF-8 payloads. The overhead of the lead-in type 
> byte was seen as worth it, even though there are many applications that 
> will only use the UTF-8 strings. So, I see the choices here as just a 
> matter of degree. I think popularity of HTTP for many kinds of 
> applications has shown that one or more features of HTTP(*) are often 
> applicable to an application's needs, while the overhead of these 
> features is low enough to be worth including them in the protocol for 
> all.(**)

Agreed, I think HTTP's framing is well worth the cost.

-rektide