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.
