Dear all,
In any case, there's a meeting of the storage providers organised by Maria to discuss this kind of thing in a couple of weeks (https://indico.cern.ch/event/311528/), so we should wait to see what comes out of that.
Just to clarify that this is a first meeting where we will try to identify priorities and organise future regular meetings to discuss Information System issues that are common to the different Storage Systems. I´m not sure there will be time for a specific discussion next week, but we will for sure include this type of things on the list of priorities. By the way, if you have a particular thing on which you need input from this meeting, please, formulate it in a more precise way since I´m a bit lost with all the mails exchanged so far. Are we talking here about capabilities, interface names, ...? It would be good to have a request from the GLUE WG that I can bring to our meeting.
No. For established names that have been in use for a long time I think changing them would be a very bad idea, it gains nothing and would be disruptive for a long time. Past experience with trying to rename things is that it's nearly impossible to remove all traces of the old name, so I would say that it should only be considered where there's an overriding reason. (Also note that the GOC DB has decided not to bring its names in line for the same reason.)
Yes, please, take into account what it is already in use. We can´t ignore that completely, we should be pragmatic as well or nobody will make use of this information. For instance, I don´t know how many people know what 'org.ogf.gfd-129' is, but most people know what SRM is. Regards, Maria
My suggestion for these two InterfaceNames would be:
org.ogf.glue.dpm.webdav org.ogf.glue.dpm.xrootd
No, that would be crazy - these are *standard* protocols, they are not in any way specific to DPM, so they need to have universal names.
How they can be used in discovery I already said in several emails. InterfaceName should NOT be used to indentify the protocol or the cababilities. For that there is existing attributes.
This is nonsense - InterfaceName is precisely the agreed attribute to identify the protocol.
Stephen -- Scanned by iCritical.