Hi Florido, On 07/04/14 11:28, Florido Paganelli wrote:
On 2014-04-04 19:01, Paul Millar wrote:
I hope you see how, given any RFC or any GFD, I know exactly how to publish a capability; and, given the capabilities of any endpoint, I know exactly which RFCs and GFDs it supports.
I can see how, indeed.
These that you listed above make more sense for InterfaceName than for Capabilities.
Sure, this is my point: currently, capabilities are too high-level and there is only one InterfaceName.
As Stephen pointed out, there is no much additional information in the reversed domain name there.
I don't really care about the reversed-domain in the name (see below).
[..] But since each Endpoint can only have one InterfaceName, then a service supporting multiple protocols should in principle have as many Endpoints as the supported protocols.
So we're back to the idea of publishing the same information many, many times. Just to be clear: this, at best, an ugly work-around. Here's an example to put the effect in context. If a StorageService publish O(10) Endpoints (not unreasonable) and each endpoint supports O(10) different RFCs (a tad high, but not unreasonable), then publishing an Endpoint for each RFC means publishing O(100) *additional* Endpoint objects, each mostly duplicating information already published.
We can overcome the above using capabilities, but then one must me more specific on what one can *do* with that protocol:
Capabilities, the way I read them as they're described in GFD.147, are ways to discover functionalities, thus the namespace is not about the organization but tells about the functionality.
Two points to consider: By itself, each RFC document says *very precisely* what functionality is supported. The problem here is that the functionality described by an RFC could cover multiple items in the capability namespace and, when not, then the choice of capability isn't automatic. There's nothing to prevent publishing the higher-level functionality in addition to the very specific RFC-based capability.
Hence if one has an Endpoint whose interface supports more than one protocol, one could publish:
data.transfer.rfc-2660 security.authentication.rfc-2660 data.transfer.gfd-47 and so on.
What do you think? what do the others think?
First off, having two representations for RFC-2660 (as "data.transfer.rfc-2660" and "security.authentication.rfc-2660") is bad. Against which capability should a client query to find an endpoint that supports RFC-2660 (data.transfer, security.authentication, or both) ? What does it mean if a storage element publishes "data.transfer.rfc-2660" and not "security.authentication.rfc-2660"? IMHO, there should be a single, canonical way of representing that an endpoint supports RFC-2660 and this should be somehow a single attribute that is published. Adding "data.transfer" or "security.authentication" as a prefix is problematic as: 1. protocols often cover multiple high-level functionalities (GFD-47 isn't only about data-transfer) 2. the mapping (RFC-2660 --> "security.authentication") isn't automatic, so we're back to maintaining an enumeration. My view is still that: o An RFC or GFD describes (completely) a set of functionality. o A client's desired interaction is very often predicated on an endpoint supporting the functionality described in one or more RFC or GFD documents. o That a GLUE2 Endpoint supports multiple RFCs/GFDs concurrently is both natural and likely. o There is considerable advantage to publishing the RFCs/GFDs that a GLUE2 Endpoint supports, such that: * A single Endpoint may publish support for multiple RFCs/GFDs. * Each RFC and each GFD has a single, canonical string value that, when published as part of Endpoint, represents support for that RFC or GFD. * The canonical value for any RFC or GFD is knowable without consulting any enumeration (i.e., it is purely algorithmic). * Given a canonical value, the corresponding RFC or GFD is knowable without consulting an enumeration. I don't care so much whether the canonical value is published as Capabilities, InterfaceExtensions, SupportedProfiles or Semantics --- provided precisely one is chosen as the correct way of publishing this information. Likewise, I don't care so much whether the canonical value for RFC2660 is 'rfc2660', 'RFC-2660', 'org.ietf.rfc-2660', 'Standards.From-IETF.RFC-2660' or 'http://tools.ietf.org/rfc/rfc2660', provided one purely algorithmic translation is chosen.
It would be nice if this is discussed among storage services developers.
There is a meeting coming up, but I'm not sure how much convergence there'll be. I think it is this groups responsibility to either accept or reject my view, as expressed above. Cheers, Paul.