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. >
