Paul Millar [mailto:paul.millar@desy.de] said:
Actually, I'd say that storing the UniqueIDs in something like a catalogue is "broken" client behaviour. I certainly feel we (GLUE) should *not* make it a requirement that UniqueIDs never change in order to support this broken behaviour.
The requirement isn't necessarily that they never change, but that there may be consequences if they do. The same is often going to be true for any URL/URI - for example desy could change its domain name from desy.de to desy.org, but there would be many consequences, e.g. that lots of email addresses and web links stored all over the world would become invalid. I think this is an underappreciated point in fact, e.g. there are still plenty of links around that point to http://uimon.cern.ch even though it was moved a couple of years ago (at least the redirection is still alive). Being more of a purist I could argue that if you change the unique name of something it in fact becomes a different thing that just happens to share some of the properties ... however, in practice most Glue UIDs are not that critical, probably SE and Site IDs are the most important to preserve (and of course the VO names).
For LAN access, you might want to advertise which machines and from which port the protocol is available (dcap, gsidcap, xrootd, rfio), or you might not (AFS, NFS, Luster, GPFS).
However, properties like hostname and port information seems to be missing from the StorageAccessProtocol entities.
If you want to publish these properties then currently one must use a StorageEndpoint.
How would that help? You still have to ask the SRM for a TURL, so what would you do with the information? (For a classic SE it's different, there you do need the endpoints.)
Also there could be other complications, for example an SE might have a gridftp server for reasons other than it being an accessprotocol (e.g. the CE currently has one to allow RTE tags to be published ...)
Sorry, what are "RTE tags"?
RunTimeEnvironment is an attribute of a CE used to publish arbitrary information about installed software, much like the OtherInfo attributes. VOs need to be able to add their own tags to advertise VO-specific software installations, so the CE has a gridftp server to allow them to deposit the information where the info provider can find it. Potentially you could have the same kind of thing on the SE.
My knowledge of CEs is rather limited, but I thought the current CEs have a gridftp server to allow transfers of user sandboxes.
That server is on the RB, but that is indeed another example of a gridftp server not used for generic data storage. Stephen