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: Re: [camp] Issue 3: alternate proposed direction

No matter what, I think we need to define two options for registering a PDP; by value and by reference. It seems that we are discussing the various options for the "by value" option.

I would claim that, since we have mechanism for registering a PDP by reference, that your option (2) is not necessary. If a PDP is too large or the network to the provider is too slow, etc. the Application Developer/Admin can upload the PDP (once) to some more convenient/better connected location (e.g. Dropbox) and use the "by reference" mechanism to register the PDP multiple times. CAMP doesn't need to get into the what/where/how's of this "more convenient/better connected" location.

~ gp

On 5/22/2013 9:16 AM, Anish Karmarkar wrote:
I think we have several options:

1) Use multipart and register the "inlined" PDP. This would result in an AT after the POST.

2) Use POST to upload, you get back the PDP URL (no multiplart). A subsequent post is required to register. This allows you to the PDP once and register it multiple times.
a) We could either use the Platform URL for the POST, OR
b) We could have the Platform resource tell the client where to POST (i.e. a new attr on the Platform resource).

3) Use POST to upload+register (no multipart). This returns the AT URL. To register the same PDP multiple number of times you have to upload it every time, unless the Platform provides some sort of "clone" mechanism via extensions.
a) We could either use the Platform URL for the POST, OR
b) We could have the Platform resource tell the client where to POST (i.e. a new attr on the Platform resource).


On 5/20/13 1:10 PM, GILBERT PILZ wrote:
+1 to not managing PDPs. If we did we would need to define a resource to
represent them, specify their lifecycle and the operations necessary to
manage that lifecycle (e.g. "update PDP"), etc. I don't see any
advantage in CAMP getting into content management.

~ gp

On 5/18/2013 5:31 AM, Alex Heneveld wrote:


We don't currently track PDP's at the platform. How about the POST
returns an assembly template?


On May 18, 2013 12:28 PM, "Anish Karmarkar"
<Anish.Karmarkar@oracle.com <mailto:Anish.Karmarkar@oracle.com>> wrote:

    Here is an alternate proposal for uploading a PDP that does not
    involve MIME, as promised:

    1. Uploading a PDP to the Platform

    To upload a PDP, a client send a HTTP POST request to the Platform
    URL with the PDP in the entity body of the request (Note:
    media-type of the request is TBD). On success, the server returns
    a 201 Created HTTP status code with the Location header that
    contains the URI that identifies the uploaded PDP.


    POST /<platform-url> HTTP/1.1
    Host: example.org <http://example.org>
    Content-Type: ...
    Content-Length: ...

    ... <PDP> ...

    HTTP/1.1 201 Created
    Location: http://example.org/paas/pdps/1
    Content-Type: ...
    Content-Length: ...


    Note that the client can use the value of the 'Location' header in
    the HTTP response to register the PDP as described in Section
    6.11. The same uploaded PDP may be registered by the client more
    than once.



To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:

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