Hi Paul, On 2014-03-05 18:30, Paul Millar wrote:
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
that sounds correct to me
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.
Paul, I think this is very bad. http is not webdav. If one searches for http endpoints that should NOT be done with interfacename, but with Capability or Technology. This http there is a very misleading thing -- in short, so how is an information consumer supposed to infer that endpoint supports webdav?? I think we should simply add webdav. If the thing is how to discover that webdav is based on http, this is another kind of question... I think of webdav as a protcol itself. If you think it as an extension of http, maybe you can play with InterfaceExtension in the Endpoint... But I think one should have a StorageAccessProtocol object just for that as well.
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.
I don't like the above. One should tell what the protocol is, not what are its close siblings. Type MUST be webdav. I am against giving such misleading recommendation as the above, they only generate confusion.
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.
In such scenario, what algorithm should the consumer use to discover a webdav endpoint? I dislike this one as well -- for the same reasons as above. Moreover would be nice to stick a domain name to those -- like org.ieee.webdav. I agree that for old standards like http there is no single organization, and is hard to tell, so there can always be exceptions, plain http and https can stay. I agree with the SupportedProfile proposal. Cheers, Florido -- ================================================== Florido Paganelli ARC Middleware Developer - NorduGrid Collaboration System Administrator Lund University Department of Physics Division of Particle Physics BOX118 221 00 Lund Office Location: Fysikum, Hus B, Rum B313 Office Tel: 046-2220272 Email: florido.paganelli@REMOVE_THIShep.lu.se Homepage: http://www.hep.lu.se/staff/paganelli ==================================================