On 9/01/2013 3:48 AM, Gregg Wonderly wrote:
I'm not convinced it's that "old". It's been around for eternity, but from a
practical perspective, there's something to be said for consistency.
But "jini" is registered with IANA, it's also registered as a dns-srv.
This is from Wikipedia:
URI schemes are frequently and incorrectly referred to as
"protocols", or specifically as *URI protocols* or *URL
<http://en.wikipedia.org/wiki/URL> protocols*, since most were
originally designed to be used with a particular protocol
<http://en.wikipedia.org/wiki/Protocol_%28computing%29>, and often
have the same name. The |http| scheme, for instance, is generally
used for interacting with Web resources
<http://en.wikipedia.org/wiki/Resource_%28Web%29> using HyperText
Transfer Protocol
<http://en.wikipedia.org/wiki/HyperText_Transfer_Protocol>. Today,
URIs with that scheme are also used for other purposes, such as RDF
<http://en.wikipedia.org/wiki/Resource_Description_Framework>
resource identifiers and XML namespaces
<http://en.wikipedia.org/wiki/XML_namespaces>, that are not related
to the protocol. Furthermore, some URI schemes are not associated
with any specific protocol (e.g. "|file
<http://en.wikipedia.org/wiki/File_URI_scheme>|") and many others do
not use the name of a protocol as their prefix (e.g. "|news
<http://en.wikipedia.org/wiki/Usenet_newsgroup>|").
URI schemes should be registered with IANA
<http://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority>,
although non-registered schemes are used in practice. RFC 4395
<http://tools.ietf.org/html/rfc4395> describes the procedures for
registering new URI schemes
The jini scheme already has existing methods for selecting different
protocols, but it's not included in the url, perhaps that's a shortcoming.
A guide for creating new uri / url sheme's:
http://www.ietf.org/rfc/rfc2718.txt
A size limit of 512 bytes is recommended.
This is multicast, and I'm not worrying about multicast, it already works, what
we want to do, is something completely different which has different network
characteristics such as firewall traversal, interaction with new Java
modularization, different forms of security etc.
Some deployments still use multicast, which depend on unicast, we need
to support that a little longer. Sounds like we might be getting our
wires crossed, I'm discussing modifying multicast packets (which must
use unicast) to include some additional information to assist unicast on
the client to determine the most suitable socket for the Endpoint to use
for unicast discovery.
You might recall Sim added a SocketFactory to LookupLocator.
LookupLocator is a value object, it didn't fit, I'd like to provide the
same functionality via alternate means.
This is where we need to "reconsider" what is going on. Endpoints are a fine
abstraction, but we want to make it possible for the protocol handler to end up with the
appropriate EndPoint abstraction that supports the protocol requirements.
Unicast lookup discovery currently uses Endpoints. All existing
Endpoints accept a SocketFactory, however discovery doesn't use it,
instead a standard socket is used, this isn't configurable.
The Endpoint used for unicast discovery can be configured.
ConstrainableLookupLocator can ensure that the right kind of Endpoint is
used.
Are you looking for a more direct way, to use your preferred Endpoint
for unicast discovery? You want your url string to specify which
endpoint to use?
Perhaps we could do that with a query string:
jini://host:port?endpoint=JERI-SSL
jini://host:port?endpoint=JRMP
jini://host:port?endpoint=RMI-IIOP
And perhaps extending it just that little bit further:
jini://host:port?endpoint=JERI-SSL,socket=MEKONG
Cheers,
Peter.
