On Jan 3, 2013, at 6:58 AM, Peter Firmstone <[email protected]> wrote:
> Gregg Wonderly wrote: >> 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. >> > > Currently we're restricted to jini://host:port URI syntax in LookupLocator, > although we have various options for discovery, these are goverened by > constraints, but then you have the problem of the client and server being > configured with different constraints and unicast discovery protocols. I don't see such a restriction since there is a LookupLocator(String) constructor. That string can convey anything, and the history of "jini:" is just history, not a requirement. People using the other constructors get "jini:" behaviors. The getRegistrar(…) methods just need to use a pluggable protocol discovery/lookup function, and then return a ServiceRegistrar implementation. Whether or not that is a "remote" reference or a "proxy service" is a detail for the protocol provider. > > We already have a number of different discovery protocol options, it would be > nice if LookupLocator reflected this. What are you imagining to be different? > > LookupLocator is often generated by way of a URI string found during > multicast discovery or from configuration, a string would also make sense for > DNS-SRV. I generate lookup locator from/in configuration. Even through I do enable multicast discovery, unicast is also happening, and I've always managed multiple discoveries using a ServiceID->ServiceItem (well with my deferred unmarshalling, it might not be ServiceItem) map. > > A handler sounds like a good idea, Sim and I were discussing something like > that recently for RiverClassLoader. Perhaps something using an SPI interface > might be appropriate, the URI scheme used to lookup up a suitable provider. Yes, this is what I am thinking along the lines of. Gregg > > Cheers, > > Peter. > >> 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. >>> >>> >> >> >> >
