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 and ServiceRegistrar
Date Wed, 02 Jan 2013 13:02:42 GMT
Dan Creswell wrote:
>>>> These methods could easily return jini://host:port for standard Jini
>>>> unicast
>>>> discovery, this allows a lot more freedom for future expansion of
>>>> discovery
>>>> methods, for very little effort.
>>>>
>>>>
>>>>         
>>> How would you see these being used in a real system? Would I want
>>> these URL's on the Registrar? See, to get them, I need to have got
>>> hold of the Registrar in the first place. Dunno, this feels like
>>> something that needs to be on an Admin interface somewhere.
>>>
>>>       
>> Got time for an example?
>>
>>     
>
> You offering or asking? Can't tell.
>
> The thing about getting these locators from the registrar itself is
> that you have to have located the registrar in some other way
> previously (e.g. via multicast).
>
> Question then would be, who uses unicast lookup locators and why?
> Developers, those messing with firewalls?
>
> And once we've agreed on that a little, what's the best way for those
> people to get and use those URLs? Perhaps they have to be shoved into
> a config file or passed on a command-line to some client? So we'd need
> a way for people to get ahold of these URL's for sure and we could do
> as you suggest but is that the best way? As I say, feels to me like an
> Admin/Config task best handled via a tool operating on an Admin
> interface or similar.
>
>   

I suppose the use case for asking the ServiceRegistrar for a URL 
(similar to LookupLocator) is weak, the client has a copy via multicast 
discovery or configuration anyway, future methods might include dns-srv 
records. 

I was thinking about protocols other than jini://host:port for unicast 
lookup, tunnelling for example, yes messing with firewalls and client 
mobility.  LookupLocator only supports the jini://host:port scheme.

Are there any other methods a next gen ServiceRegistrar could benefit 
from?  Once it's released, were stuck with the interface.

>>> I would certainly say StreamServiceRegistrar is the wrong place to put
>>> them. They have nothing to do with Streaming at all. That's okay,
>>> StreamRegistrar is becoming a next-gen ServiceRegistrar interface but,
>>> if it is, we need a different name.
>>>
>>>
>>>       
>> Sounds like you've a better name in mind?
>>
>>     
>
> Heh, hell no. When we did the JavaSpace extensions we ended up with
> JavaSpace05 because we had such a mixed bag of bits.
>
> If we're gonna follow that style though we'd have ServiceRegistrar13
> or 14 for the superstitious :)
>   
Hmm, maybe ServiceRegistrar2?   Perhaps it should be moved into the same 
package as ServiceRegistrar?

I figure it's about time we added JavaSpace05 to the Jini Specifications 
as well, I've written it up locally using wording from javadocs.

Findbugs identified some concurrency issues with Outrigger.  I've been 
wondering if we should drop Outrigger and promote Blitz and Rio instead, 
hey they've got dedicated maintainers ;)  It would be relatively 
straightforward to set up a JavaSpace TCK from the qa suite.

I was also thinking about the benefits of dropping Phoenix, we could 
support other JVM's.  Phoenix ties us to Sun JVM proprietary 
implementation classes.  Activation isn't part of the Jini spec anyway.

I'd also like to remove TaskManager and other implementation classes 
that could be replaced by Java concurrent libraries.

Slim things down to reduce the maintenance burden somewhat.

Cheers,

Peter.


Mime
View raw message