river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: LookupLocator and ServiceRegistrar
Date Wed, 02 Jan 2013 09:18:10 GMT
On 1 January 2013 09:48, Peter Firmstone <jini@zeus.net.au> 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.

View raw message