Hi Stephen, Maria, everyone else, On 05/03/14 13:22, stephen.burke@stfc.ac.uk wrote:
Maria Alandes Pradillo [mailto:Maria.Alandes.Pradillo@cern.ch] said:
On behalf of the DPM team, could you please also consider adding:
I think these do need some more discussion ...
- "DPM" to ServiceType
It isn't clear to me that DPM is a distinctive type - as far as I know it only implements standard interfaces like SRM and xroot, so why is it a different type of service to, say, dcache? What would you propose as a definition? DPM as a product name is published elsewhere. I think we probably need a type name that would be common between, say, DPM, dcache and Castor since they provide basically the same functionality.
For comparison, dCache currently publishes a Service.Type of 'org.dcache.storage' I think we've already had a discussion on this point, without coming to a conclusion, as I recall. The problem (IMHO) is the level of detail depends on who's asking the question. Stephen, to you DPM, dCache and Castor provide the same functionality, so you would be happy with instances of all three published as Service.Type of 'storage' (or similar). Somebody who needs some unique characteristic provided by dCache (or DPM, or ...) might want more detailed Type, specifically that the service provides the dCache-like facilities (or DPM-like or ...). If all someone wants is to store some data using, say, WebDAV, then they can look for a WebDAV endpoint that they're authorised to use. They wouldn't even look at the StorageService Type. That isn't to say publishing DPM (or 'org.dcache.storage') is the correct approach, but that saying "they're all storage" also isn't necessarily correct. So, in the absence of other compelling reasons, I would suggest going for a *more* specific Type: the generic features may be published elsewhere (e.g., as endpoints) and searched for as such. The only thing I would suggest is that instead of publishing DPM, you publish a reasonable DNS name. A three-letter acronym is perhaps generic enough that it might result in confusion.
- "org.webdav" and "org.xrootd" to InterfaceName
xroot has already been discussed extensively and we made a decision - I think the decision was to use "xroot" for the protocol name but we should check.
For the xrootd protocol, dCache currently publishes Endpoint.URL: xroot://xrootd-door.example.org/ EndpointInterface.Name: xroot and StorageAccessProtocol.Type: xrootd
For webdav I think the "org." prefix isn't adding much here - probably we should just use "webdav" as it's a well-known protocol defined in an RFC so there's no issue of a name clash, but there may be other views. Anyway there are likely to be other interested parties - dcache at least - who should express a view.
For WebDAV, dCache is currently publishing as either 'http' or 'https', depending on whether SSL/TLS tunnelling is enabled or not. This is for Endpoint.URL ('http://' or 'https://'), Endpoint.InterfaceName and StorageAccessPoint.Type. This is largely for historical reasons (dCache supported HTTP before WebDAV) -- not to say this is correct. Since HTTP is a subset of WebDAV, it would be useful if someone searching for HTTP endpoints could also find any WebDAV endpoint. Therefore, here's a concrete proposal: --- A service that supports HTTP or WebDAV protocols MAY publish StorageAccessProtocol objects to represent this. If a StorageAccessProtocol object is published to represent HTTP access then the Type SHOULD be 'http'. If a StorageAccessProtocol object is published to represent WebDAV access then the Type SHOULD be 'webdav'. Since HTTP is a subset of WebDAV, a service that publishes a WebDAV StorageAccessProtocol SHOULD publish a StorageAccessProtocol for HTTP. When publishing an Endpoint object the describes an HTTP or a WebDAV endpoint with unencrypted access then the URL SHOULD start 'http://' and the InterfaceName SHOULD be 'http'. If the endpoint is encrypted then the URL SHOULD start 'https://' and the InterfaceName SHOULD be 'https'. If the endpoint supports WebDAV then a SupportedProfile of 'http://webdav.org/' SHOULD be published. --- Cheers, Paul.