river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gregg...@gmail.com>
Subject Re: Discovery v3
Date Mon, 07 Jan 2013 20:22:01 GMT
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 <jini@zeus.net.au> 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.
> 


Mime
View raw message