Thanks Dan, I'd like to get the semantics right.
Cheers,
Peter.
On 9/01/2013 7:51 AM, Dan Creswell wrote:
It sounds like the socket provider is a separate concen from the uri string, to
enable substitution of socket providers.
Not so sure. See there's protocol and transport for the protocol. One
needs both in order to get a connection and do stuff with it. That
means that whilst there might be a library of socket providers, and a
library of protocols, one can't "cross" any with any meaningfully
because of standard conventions enforced at firewalls and so on.
So I reckon we need something that can specific the whole stack,
whether we like it or not. There will of course be "obvious" defaults
for various situations, again defined by convention.
Gonna take some thought I reckon....not something to hurry into. I'm
gonna have to sit back and see if I can think of some prior art in
this area to look at.
SocketAddress is an abstract class and Sockets are just endpoints for
communication between two machines.
Sockets don't need to be trusted, simplifying discovery trust issues, trust is
left to the jeri endpoint used over that socket.
Cheers,
Peter.
