On 2 January 2013 13:02, Peter Firmstone <[email protected]> wrote: > 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. >
Yeah, that's kinda where my mind is going. I'd like to see a real-need emerge to drive the change and I can't see it at the moment. S'why I'm asking you and anyone else to wade in... > Are there any other methods a next gen ServiceRegistrar could benefit from? > Once it's released, were stuck with the interface. Mmmm, well I hadn't thought about it much at all. Was just doing my usual architecture hat feedback. I guess we should look back through the archives and see what others think too. > > >>>> 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? > re: package, yes. re: name, that's fine with me, although someone, somewhere must surely be able to come up with something better ;) > 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. > Yes, I was around at the time and, to all intents and purposes, the JavaDoc was seen as the spec so there'd be no problem with that. > 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've never actually run findbugs against Blitz, it may be worse :) > > 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. > >From recollection only, Phoenix will do basic security type stuff that rmid doesn't do. Probably some thinking to do there. A quick google reveals: http://river.apache.org/doc/release-notes/execpolicy.html > I'd also like to remove TaskManager and other implementation classes that > could be replaced by Java concurrent libraries. > No reason why not. > Slim things down to reduce the maintenance burden somewhat. > Smaller codebase is always good. > Cheers, > > Peter. >
