Re: [camp] Issue 3: alternate proposed direction

[GILBERT PILZ <gilbert.pilz@oracle.com>]

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).
>
> -Anish
> --
>
> 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:
> > > Anish,
> > >
> > > We don't currently track PDP's at the platform. How about the POST
> > > returns an assembly template?
> > >
> > > Best,
> > > Alex
> > >
> > > 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.
> > >
> > >     Example:
> > >
> > >     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.
> > >
> > >     Comments?
> > >
> > >     -Anish
> > >     --
>
> ---------------------------------------------------------------------
> 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:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php