>>> 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 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 :) > Cheers, > > Peter. >
