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. 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. > Thoughts? > > Regards, > > Peter.
