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] Commented: (CAMP-150) mechanism for creating an Assembly (or Plan) by value (i.e. POSTing the contents of a PDP or Plan file) is difficult to use


    [ http://tools.oasis-open.org/issues/browse/CAMP-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36027#action_36027 ] 

Gilbert Pilz commented on CAMP-150:
-----------------------------------

It seems clear to me that we need to resolve this by specifying the use of multipart MIME and the "multipart/form-data" Content-Type for uploading PDPs and Plan files as we did in previous drafts. In order to be interoperable, we also need to specify the value of the "name" attribute for the part that contains the file data. For example:

------WebKitFormBoundaryU6AnBoMxAEBre6sl
Content-Disposition: form-data; name="pdp"; filename="VitaMinder.pdp"
Content-Type: application/x-zip

If we don't specify this value, we are effectively saying that all Providers must supply an HTML form which specifies this value (as the control name of the file select control) and that all clients must read and process this HTML - otherwise how does the client know what to name the part? Neither of these constraints seems reasonable to me as I can imagine any number of reasons why a Provider may not wish to supply an HTML form and why a client (e.g. Eclipse) may not wish to deal with HTML.

What I'm wondering is if it makes sense to specify different names for PDPs and Plan files (e.g. name="pdp" vs. name="plan") or if we should just use a single name for both (e.g. name="campFile")?



> mechanism for creating an Assembly (or Plan) by value (i.e. POSTing the contents of a PDP or Plan file) is difficult to use
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMP-150
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-150
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Spec
>            Reporter: Gilbert Pilz
>            Assignee: Gilbert Pilz
>            Priority: Critical
>
> We've been back and forth on this a couple of times but, be that as it may, the current version of the spec (WD 29) defines a mechanism for creating either Assemblies or Plans by value that makes it difficult to write simple clients for CAMP. Specifically, Sections 6.11 and 6.12 WD 29 says that the contents of either the PDP or the Plan file should be placed in the body of the POST request message; no multipart/form-data etc.
> This mechanism make it difficult to write a simple client that can upload applications to an CAMP cloud. HTML forms will not work, there are no Javascript libraries (that I can find) that work this way, even soapUI can't be made to do this (nCAMP implements an extension that accepts multipart/form-data requests). It might not seem like a big deal, but I believe that the inability to support simple clients will have a large negative impact on CAMP's adoption. For someone not sure of the benefits of CAMP, making them jump major technical hurdles to implement their first use case is likely to cause them to give up and write CAMP off as "too complicated".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


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