On Jan 5, 2013, at 3:25 AM, Dan Creswell <[email protected]> wrote:
> On 5 January 2013 05:10, Gregg Wonderly <[email protected]> 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
