Dan Creswell 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.
Most instances of LookupLocator are built from the results of multicast,
so the URI form makes sense.
I've implemented a LookupLocator2 that uses URI and MethodConstraints.
There are some gotcha's with equality and normalisation, so it's
probably good to have a wrapper class similar to LookupLocator to ensure
normalisation is compliant with RFC3986, it's the only revision of the
spec that allows equals comparisons to be made reliably on URI,
normalisation is very important.
Cheers,
Peter.
