On Tue, 2014-11-18 at 17:41 +0000, Gordon Sim wrote: > On 11/18/2014 05:29 PM, Andrew Stitcher wrote: > > On Tue, 2014-11-18 at 09:35 -0500, Rafael Schloming wrote: > >> 2. Given that we have a distinct configuration phase regardless, it is > >> simply unnecessary to force people to choose client vs server up front. We > >> can simply default the mode to client and have people set it to server > >> during the configuration phase if that is what they wish. > > > > As clients and servers are fundamentally different in usage it makes no > > semantic sense to me to create a client then "turn it into" a server. > > This is the context that I think I'm missing: why are they fundamentally > different?
Despite the AMQP protocol being symmetric once established, the establishment cannot be symmetric. One party must initiate the connection (the TCP client) and one must be listening (the TCP server). > Clearly with respect to sasl, the distinction is important in order to > infer their roles. Likely the same is true for ssl. The JIRA also > mentions a server being able to automatically adjust to clients selected > layers if desired, which sounds nice. Fundamentally a client must know which protocol layers it is going to use, and a server can adjust the layers to whatever the client is using. > > However this doesn't seem fundamental to me, it seems like a > configuration of the handshaking behaviour after which usage will be > pretty much exactly the same. I'm thinking that this handshaking behaviour *is* fundamental to the purpose of the transport, as the major purpose of the transport is to coordinate the layers that are used to process the incoming byte stream. The transport client/serverness is not fundamental to the messaging semantics layered on top of it though. Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
