Re: A precedent suggesting a compromise for the SWHCLS IG Best Practices

> You may well be correct in your thinking that a similar approach 
> offers a good compromise. In fact to my mind it may actually leave 
> everyone with something that is significantly stronger than what we 
> have currently and the fact is that the software required to support
> it already exists [1] modulo a few tweaks. 
> 

To expand a little on why I am coming to believe this approach has a 
number of technical advantages, please consider the following 
possibilities:

1] The same gateway server software that would run at http://lsid.info/ 
(for example) can also be run locally by any party. 

2] A DNS entry can be established locally to return for all ip address 
requests for hostname lsid.info their local gateway server?s address 
instead - perhaps at the organization/geographic location/machine cluster 
level.

3] An organization's local gateway server behaves in exactly the same way 
that the centrally located gateway server does (which is why it can safely 
provide that service in its stead), except that it may in addition have 
access to data/metadata services that are behind the firewall for that 
organization.

4] Any gateway server can safely & indefinitely cache and re-serve out all 
LSID named data that it retrieves.

5] The result would often be fast single access dereferencing of those 
data objects from local caches. There would also be far less traffic for 
the central gateway service and privacy of the dereference requests are 
guaranteed.

Programs have the option of either dereferencing LSID URNs using the 
existing DDDS based resolution protocol (which is how the gateway server 
software would do it) or by applying the appropriate transform to any LSID 
URN to create a URL in the manner suggested by Henry and the ARK paper. 
URN:lsid:myorg.org:namespace:objectid:v1 would morph to something like 
http://lsid.info/lsid:myorg.org:namespace:objectid:v1 I would expect this 
to be trivial to implement even in a Web 2.0 style application executing 
in a browser. 

Data providers need only continue to serve their data/metadata using the 
existing standard LSID mechanism. All the requirements for a decentralized 
naming and data/metadata service discovery scheme continue to be met (the 
named objects remain independent of location and transport protocol & 
there is no central point of failure) while at the same time the gateway 
scheme would additionally provide _stable_ global and optionally local 
http URL access to all accessible LSID named data objects and metadata 
along with possible performance benefits. 

Little new programming & standards work would be required.

Kindest regards, Sean

--
Sean Martin
IBM Corp