OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] (CAMP-177) Metadata Bootstrapping at the platform_endpoints level

    [ https://issues.oasis-open.org/browse/CAMP-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58763#comment-58763 ] 

Gilbert Pilz commented on CAMP-177:

Hi Mike,

The reason that we linked the tree of type definition metadata from the "platform" resource is that the resource model is dependent on the version of the CAMP spec being used, and "platform" is the version-specific root of the resource tree. The "platform_endpoints" and "platform_endpoint" resources essentially serve as bootstraps that allow version-aware clients to discover which versions of CAMP a provider supports. The use of these resources isn't strictly necessary. You could write your client to simply start from a particular "platform" resource (i.e. you have to supply it the URI of a "platform" resource instance).  Version-aware clients are expected to have a priori knowledge of the structure of the "platform_endpoints" and "platform_endpint" resources. This is why the CAMP spec contains the following warning text in the descriptions of these two resources:

"Note: Because of its unique function, future versions of the CAMP specification are cautioned against making non-backwards compatible changes to this resource."

Does that help clarify things?

> Metadata Bootstrapping at the platform_endpoints level
> ------------------------------------------------------
>                 Key: CAMP-177
>                 URL: https://issues.oasis-open.org/browse/CAMP-177
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Spec
>            Reporter: Martin Chapman 
> https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201502/msg00006.html
> Hi guys,
> I’m new to this list and to working with the API so please tell me if there is another place I should post this. 
> I may be missing something completely obvious, but I’ve hit a problem.
> I’m trying to understand how I can source the metadata about the API in order to write a GUI client which constructs itself based on the metadata it sees.  That way my client is only dependent on the structure of the  API and doesn’t need to carry any semantics of the API itself, and so I can extend the API without having to write any new GUI code.
> So, the obvious way to do this seems to be for the platform_endpoints resource to carry the metadata for the entire domain. However, the metadata is present in the type_definitions_uri of the platform Resource, which causes a couple of problems.
> •	The platform resource has a one-to-many relation with the platform_endpoints resource, so the platform_endpoints’ metadata sourced from the set of platforms is potentially ambiguous.
> •	The platform is behind authentication and the platform_endpoints resource potentially isn’t
> •	If we extend the platform_endpoints resource the only way we can retrieve the metadata is from a platform that knows about that extension. This breaks the loose coupling across the parent-child relation  afforded by the Links (which is really nice, by the way)
> I can see that there is a problem with versioning of metadata and the Platforms need to run with different versions and this may be why you’ve done it this way.  However, I can’t see a way of dealing with the three problems above without extending the API – and making my GUI dependent on that extension being present, which kind-of defeats the point.
> The specific extension I have been looking at involves carrying the metadata of the Resource into their corresponding List resources (e.g. putting the metadata for the platform_endpoint into the platform_endpoints resource). 
> Any help with this would be appreciated.
> Thanks,
> Mike

This message was sent by Atlassian JIRA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]