I too use static locator configuration because I am usually one of the administrators across a VPN connection, and my other users are remote users, not local to the multicast TTL.
I wonder if we shouldn't think about a pluggable system something like URLStreamHandler. That is, an abstract class that has pluggable protocol handlers which could be added to the system via configuration, or programmatically via a security based authorization. Then, we can use LookupLocator, but just move to a multi-protocol lookup facility. The idea of "multicast" is interesting, but its a local network segment technology, at most, to be dependable. I've not been able to ever "count" on it working. So, looking at DNS-SRV would allow us to "find" URLs. We might think about a different/refined multicast or rendezvous kind of thing, but I am not sure we can make multicast-discovery be and more dependable with just software. It's a network infrastructure issue. Gregg On Jan 2, 2013, at 4:49 AM, Peter Firmstone <[email protected]> wrote: > Dan Creswell wrote: >> On 1 January 2013 09:48, Peter Firmstone <[email protected]> wrote: >> >>> You might remember an earlier discussion on the list about >>> StreamServiceRegistrar: >>> >>> public interface StreamServiceRegistrar extends ServiceRegistrar{ >>> ResultStream lookup(ServiceTemplate tmpl, Class[] entryClasses, >>> int maxBatchSize, int limit) throws IOException; >>> } >>> >>> ResultStream is similar to MatchSet from JavaSpace05, it allows local >>> filtering of ServiceItems (with only Entry's unmarshalled), delayed >>> unmarshalling and stream like retrieval of ServiceItems. >>> >>> Well, I've been considering how LookupLocator is restricted to >>> jini://host:port based URI and figured that in future it may be preferable / >>> desireable to perform Unicast Discovery using other methods. >>> >>> I'm considering another method for StreamServiceRegistrar: >>> >>> namely something like: >>> /** >>> * Returns an array of URI that can be used if necessary >>> * for unicast discovery of the lookup service. >>> */ >>> public URI[] getUniversalLocators() throws IOException; >>> >>> or: >>> /** >>> * Returns a space separated list of URI strings that >>> * can be used if necessary for unicast discovery of the >>> * lookup service. >>> */ >>> public String getURI() throws IOException; >>> >>> >>> 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? >> 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? > > Cheers, > > Peter. >
