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=59589#comment-59589 ] 

Gilbert Pilz commented on CAMP-177:
-----------------------------------

Uploaded partial proposal here: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/55630/camp-spec-v1.2-wd03-issue-177-v1.doc

> 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
>    Affects Versions: 1.2
>            Reporter: Martin Chapman 
>            Priority: Critical
>
> 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
(v6.2.2#6258)


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