river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: LookupLocator and ServiceRegistrar
Date Sat, 05 Jan 2013 23:08:43 GMT

On Jan 5, 2013, at 3:25 AM, Dan Creswell <dan.creswell@gmail.com> wrote:

> On 5 January 2013 05:10, Gregg Wonderly <greggwon@gmail.com> wrote:
>> 
>> 
>> LookupLocator is not something that should be "passed around".  It is information
that indicates a destination.  The URL/URI form is all we should plan for, for the future.
 This means that all dynamically discovered ServiceRegistrar instances, should be identified
as the URL string and then the appropriate protocol handler will be able to extract the information
from the URL/URI to connect and provide lookup services.
>> 
>> Gregg Wonderly
>> 
>> 
> 
> Indeed, I think it's serializable mostly because services typically
> have a requirement to remember them/be stateful, treating config
> purely as the initial startup source of lookup information. Which
> means it's convenient to serialize this stuff to disk.

I guess this is the more interesting thing to discuss.  What I am trying to say is that LookupLocator
is a programming construct, not a configuration construct.  There are plenty of other things
about "connecting to a ServiceRegistrar" then the information that it currently contains.
 Peter highlighted some of those details, and I think the basic evolution of Jini more or
less missed tying all of this stuff together because of the "data" and "functional" components
of many of the classes where behavior and data, though used together, should not of been together.
 Separating these two things for ServiceRegistrar connectivity, in particular would simplify
a number of issues about evolution, because extra data items in LookupLocator would be ignored
by V1 and then V2 discovery as needed.  Certainly, the deserialization would need to be "versioned"
appropriately, but that is possible.

Gregg Wonderly
Mime
View raw message