river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: LookupLocator transport dependence
Date Thu, 12 Nov 2009 12:23:55 GMT
I like it Sim, we need more people around here who read the code, 
question implementations and come up with good ideas.

Cheers,

Peter.

Sim IJskes - QCG wrote:
> Gregg Wonderly wrote:
>> Wow, I had not chased through all this code.  I had assumed that 
>> LookupLocatorDiscovery would use LookupLocator.getRegistrar() when in 
>> fact it does not, and recreates all the processing itself and uses 
>> introspection to reference the getRegistrarMethod for constraints, 
>> but otherwise does not call it.
>
> The whole jini package is also what you could call, rather TCP bound. 
> The upper layer of JERI is transport neutral. I saw this as an 
> opportunity to create a firewall traversing jini.
> But when you look at other subsystems, you will see a direct 
> dependence on Socket, and the assumption that an 'transport endpoint' 
> is identified by a host and port (like the LookupLocator).
> The strangest thing here, is altough the LookupLocator has this 
> getRegistrar() only the port and host properties are used.
> LookupLocator is used a _lot_, and to me it seems like it needs to be 
> changed to a more transport neutral implementation.
>
> It is possible to implement a LookupLocator via JERI. Reggie itself 
> exports itself already. The only things we need is an agreed Uuid 
> (configurable ofcourse) and a default for a ServerEndpoint export.
>
> After this we can step-wise improve all the discovery subsystems to 
> use the getRegistrar() method instead of relying on the properties.
>
> A neat thing would also be, a configurable way to silence the existing 
> unicast discovery server already built in Reggie.
>
> Any objections? :-)
>
> Gr. Sim
>


Mime
View raw message