That's old school mate, in uri, shemes aren't protocols, that's historical. Schemes should also be registered.
There's something more going on here, we need to think it over. Lets look at how the discovery protocol works now (somewhat simplified): Your client, using multicast discovery recieves a udp version 2 packet, it contains the following: Protocol version multicast packet type discovery format id discovery format data (bytes) The discovery format data encompasses all data from the end of the format id to the end of the packet and is encoded according to the discovery format indicated by the discovery format id. Which contains: Host port lookup service id member groups sequence number. A size limit of 512 bytes is recommended. The client then performs unicast discovery using a tcp Socket, with the hostname and port provided. So far we're considering replacing the host and port with a uri string. But there's a need also to allow custom Socket's as Sim demonstrated with disco v1 and LookupLocator. URL handlers aren't suitable, they only perform retrieval, we need a bi directional socket connection. It sounds like the socket provider is a separate concen from the uri string, to enable substitution of socket providers. 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. ----- Original message ----- > Humm, that "protocol" specifier has, in all current usages of URI/URL that > I've > got experience with, specific transport included in the protocol. HTTP, is an > application protocol, which assumes a "streaming socket" connection to TCP > port > 80. Other application protocols have similar details. HTTPS is used for ssl > encapsulation of the "streaming socket" connection. It imposes a different, > default TCP socket (443), since the actual transport negotiation, which occurs > up front, needs to progress differently than port 80. > > I don't think there is any practical reason why the protocol/scheme name can't > be used to select a driver/stream-handler like software implementation. The > protocol handler will have the scheme of the URL will it not? > > Gregg Wonderly > > On Jan 7, 2013, at 4:42 AM, Peter Firmstone <[email protected]> wrote: > > > On 7/01/2013 11:32 AM, Gregg Wonderly wrote: > > > I think that using "reference" rather than a protocol string is not a > > > good > > > idea, because it puts this important differentiation at the end rather > > > than > > > first. Just using > > > > > > jini: for discovery V1 or V2 > > > usb: for something over a USB interface of yet to be decided nature > > > udt: for UDT > > > mekong: for mekong > > > > > > etc., would be the right choice. For me, that would provide a better > > > bases > > > for a protocol handler/driver mechanism. > > > > > > Gregg Wonderly > > > > I did consider that, but it clobbers dns, we loose the scheme information, > > making life harder if we wanted to do dns-srv discovery. (Not that you'll > > use > > dns-srv for usb, but you might for mekong or udt). > > > > Someone using dns srv to discover udt won't know whether it's jini or > > something else. > > > > You're right though, using the fragment or reference component is a hack. > > > > We could use the path segment, it has no meaning presently for discovery, > > jini://. > > > > "/" could potentially be used as a separator for nested Socket providers. > > > > This might allow the client and server to nest Sockets in an identical > > hierarchy. > > > > discovery SSL > > | > > DeflateSocket (compression) > > | > > MekongSocket > > > > Cheers, > > > > Peter. > > >
