Re: [hybi] Connection Strategy

[Greg Wilkins <gregw at webtide.com>]

Frank Salim wrote:
>> You seem to have some fairly strong opinions about the direction we
>> should be taking here, but as yet I don't have a clear and concise
>> understanding of your perspective.  Perhaps you could provide a
>> concrete proposal for the list to evaluate (in a separate thread) ?
> 
> Greg,
> 
> What connection strategy do you propose to use in the transport layer?


Without the context of a specific messaging system, I'm not exactly sure
I can define a connection strategy.

Firstly we should look to the connection strategies of other
messaging based protocols and see what works and what does not
work for bidirectional communication.  HTTP and BEEP are probably
good places to start.


But broadly speaking,  I believe that connection management should be
transport issue.  Applications that send/receive messages should not
care what connection(s) were used or if those connections are shared
or not (as it is for XHR/HTTP today).

With the exception that the existence of a connection can
often be used to indicate the ability (or lack of ability)
to send/receive messages

So at an application level, perhaps there can be an abstract
conduit/channel/pipe  whose existence and state can be manipulated
and tracked by the application.  Failure of a conduit can be used
to trigger application events.

However, I do not believe that there should be a 1:1 mapping between
such a conduit and a TCP/IP connection.   That should be the job of
the transport and hidden from the application/API.

[ Note that while websocket appears to expose connections
to the application - if that was renamed conduit and decoupled
from a direct relationship to the wire protocol, then I think
the API is not far from what I'm advocating. ]


For addressing and security, I agree with John that the URI and
Origin approach look appropriate.  But we need to consider what
URI and origin mean for bidirectional non request/response communication.
One possible definition is that:

 client to server:    URI is the destination of the message.
                      Origin is of the source client code, but can't be trusted.

 server to client:    URI is the source of the message
                      Origin is the source of the message
                      Accepted-origins constrains the allowed handlers in client


This is somewhat asymmetric, but probably has to be so given
that clients are mostly not addressable (else we would have this
problem) and are not trusted.


Regardless of their exact definitions, I think that address and
origin are attributes of a message (or perhaps of an abstract conduit),
but not attributes of specific connection.

Connections need to be defined so that they can be used
for mixed addressing and origins (eg in the examples I
gave of an SSL aggregation or of mashed up widget connecting
to the same server.   But it would also be good to allow
for less complex (unshared) connections that make the optimization
for a connection carrying once conduit to assume URI and origin
(as websocket currently does).

The key thing is that the application should be unaware which
type of connection is being used.



cheers