[glue-wg] New Endpoint and Service types

[Paul Millar]

Hi Stephen,

On 07/04/14 18:49, stephen.burke at stfc.ac.uk wrote:
> Paul Millar [mailto:paul.millar at desy.de] said:
>> At this stage, I'm happy if we can agree that publishing the set of
>> RFCs an Endpoint supports is reasonable thing to do :-)
>
> I'm not strongly opposed to this as a concept, but I would make a
> couple of points. Firstly, many grid protocols don't have RFCs or
> GFDs so this can't be a universal mechanism.

Agreed --- although I would hope the number of endpoints using 
non-standard protocols decreases over time.

 > Secondly, as far as I'm
> aware we so far have only one case, i.e. webdav/http, where there is
> a real issue, so we should beware of ending up with something which
> would complicate publishing and querying for the vast majority of
> cases which work perfectly well already.

This is in the back of my mind, too.  Publishing RFCs seems a reasonable 
solution for HTTP and WebDAV (especially as WebDAV itself isn't really a 
single protocol), but does this make publishing other things harder?

I don't think so.


>> The description of InterfaceExtension is almost semantically null:
>> "the identification of an extension to the interface protocol
>> supported by the Endpoint." -- there's nothing about what an
>> extension *is*, but there is a hint that this has something to do
>> with protocols.
>
> I already explained the history of this - we have never defined the
> usage of InterfaceExtension up to now because it was never needed,
> but that's no reason not to do it now if we do need it.

OK.

>> SupportedProfile also has a semantically null description (again,
>> what is a profile?), but I can guess what is meant.  RFCs could be
>> published as SupportedProfile legitimately, but this probably
>> wasn't the intention of this attribute.
>
> Again, I don't think we've ever had a use which required us to define
> it. I would conceptually see this as going in the opposite direction,
> in the sense that InterfaceExtensions would be something additional
> to the basic Interface, whereas a profile would be a restriction or
> specialisation.

That was pretty much my thoughts too: that SupportedProfile describes 
additional constraints not required by the underlying protocol, whereas 
InterfaceExtension describes additional functionality not described in 
the primary protocol.

So, in summary, publishing RFCs in InterfaceExtention would be OK, 
bearing in mind your other concerns.

Cheers,

Paul.