[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [camp] Issue 3: proposal direction with two choices
On 5/14/13 6:33 AM, Alex Heneveld wrote:
Hi Anish- What I'm suggesting is to try to avoid making the clients have to do multipart as it is irritating. Can we support registering through a simple POST whose body is a YAML DP or a ZIP/TAR PDP ?
Interesting that you bring this up. That was exactly my proposal many many moons ago: A simple POST with the PDP as the only content of the HTTP request entity body to the Platform entry point URL would result in the PDP being "made available" to the platform. The HTTP response would then contain the "Location" header that provides the URI for the PDP. Subsequently one can then register the PDP (possibly multiple times) using the existing method in the current draft. I still prefer this way of doing things. I'll send an email with that proposal again and link it in JIRA as an alternate proposal.
This way a user could write a simple curl to register a DP (and same in JS, CLI tools, etc).
I agree this is a simpler way.
I lean towards _also_ requiring support for multipart/related on the server. However not sure the "pdpUri" attribute is a necessary level of indirection. Particularly if within the DP we support imports to other DP's -- we don't yet, but we have said we would. Assume we had an "import: <href>": The first item in the multipart can be a DP YAML which says "import: cid:item2" then "item2" in the mutlipart might be another YAML DP or a ZIP/TAR PDP.
If we accept the alternate way of uploading a PDP as mentioned above. I would say that this becomes a separate issue of how to enable registering a PDP with an 'aggregation' method. We can decide to support that by allowing a POST that just contains just the DP (which in turn contains pointers to other artifacts) OR leave that as an extensibility exercise.
-Anish --
Make sense? > you need ... another part that tells the platform what to do with the PDP (in this case, register). Maybe this is the confusion. I'm assuming the "register" action is implicit, so we need only supply the PDP. Is there a reason we can't do this? --A On 14/05/2013 14:03, Anish Karmarkar wrote:On 5/9/13 12:26 PM, Alex Heneveld wrote:Hi Anish- Glad you updated CAMP-3 with this link. Somehow I missed it first time round! Obviously it raises a question about my draft proposal for CAMP-65... Q: What are the benefits of "pdpUri: cid:XXX" multi-part versus my suggestion of a single part and is it worth the overhead? *I don't know how it could be done with a single part without sacrificing requirements (at least as I see them). The problem I'm trying to solve is: I have a PDP (whatever form it takes) and I want to register that PDP by-value. The current draft already support registering a PDP by-reference. To support by-value, you need one part that contains the PDP and another part that tells the platform what to do with the PDP (in this case, register).To attempt an answer I think it makes it easier for javascript to upload as it won't have to build ZIPs on the fly. That's pretty compelling. But _requiring_ multipart from the client can also be tedious so my vote would be to require a platform to support EITHER a single part post which is interpreted as I described, or a multipart post where the first part is either the map containing { pdpUri: cid:XXX }, in YAML format (so allowing JSON), or possibly the pdp itself. (I think I prefer the latter unless there is a good reason for the former?)Not sure I understand what you are proposing, but my proposal does provide a map along with the PDP.Having the deployment plan also support cid: is nice as then artifacts could be part of the same multi-part.Perhaps you can explain this on the call, as I'm not sure what you mean. Are you suggesting that PDP be a MIME format (instead of zip or tar)?* = also have we settled on how we treat abbreviations in camel case? i prefer pdpUri to pdpURI (otherwise you risk getting HTTPRESTAPI !)Agree, we should be consistent and settle on one. -Anish --You also raised ... Q: multipart/form-data vs multipart/related I'm not sure. Will have to investigate, but not now as I'll miss my flight! :O You've probably chosen the right answer already of course. Best Alex On 01/05/2013 01:49, Anish Karmarkar wrote:Preamble I have had a long standing AI to provide a proposal for issue 3 [1]. In the past we have talked about (in this TC as well as in the collaboration) allowing clients to POST to the platform endpoint to upload a PDP. Subsequently, we have talked about allowing clients to include a PDP in their register request (see section 6.11 in WD09 [2]). If we are going to allow clients to include PDP in their register request: 1) we (the spec) would have a well-defined interoperable way to upload and register a PDP, and 2) we can stay silent on how the platform does management of repositories/content. A platform can choose to allow someone to upload a PDP or manage a platform administered repository, allow for git push, partial updates etc -- this would be a platform specific extension. Given all the various ways a platform can manage this, best to stay silent. If you agree to the following, I would like to propose the following as a directional resolution for issue 3. Proposal (Directional) Section 6.11 currently allows one to POST a JSON message: {"pdp_uri" : "<uri-of-the-pdp>"} to the platform URI and get back a Location URI for the newly created AssemblyTemplate. This section would be modified to allow for the client to send a multipart MIME message, the root part of which would contain the same JSON message as before, but the URI would be a "cid:" uri [3]. This cid uri would point to another MIME part in the same POST message that contains the PDP. For example: MIME-Version: 1.0 Content-Type: ... ;boundary=MIME_boundary; --MIME_boundary Content-Type: application/json Content-ID: <123456@example.org> {"pdp_uri" : "cid:abcdef@example.org"} --MIME_boundary Content-Type: application/zip Content-Transfer-Encoding: binary Content-ID: <abdcef@example.org> // binary octets for zip --MIME_boundary-- The advantage of keeping the same root part as before (in section 6.11) is: it will always be processed the same way. *Where* the PDP is located obviously changes, based on the URI scheme. Furthermore, if we decide to allow parametrization of register operations (which we should, but that is a different issue) then again the expression and processing of those parameters remain the same regardless of whether the PDP is provided by value (in the POST request entity-body) or by reference (eg, a http URL). Open Issue What should the content-type of the multipart message be? There are two possible options: multipart/form-data [4] or multipart/related [5]. 1. multipart/form-data This is very HTML friendly and supported by most browsers. The CAMP platform can provide such an HTML. The message would look like this -- MIME-Version: 1.0 Content-Type: multipart/form-data; boundary=----MIME_boundary ------MIME_Boundary Content-Disposition: form-data; name="pdp_uri" cid:abcdef@example.org ------MIME_Boundary Content-Disposition: form-data; name="pdp"; filename="pdp.zip" Content-ID: <abdcef@example.org> Content-Type: application/zip //binary octet for zip ------MIME_Boundary If we decide to go with this, then it would make sense to use the media-type x-www-form-urlencoded for the case where the PDP is provided by reference (the current method in section 6.11). There are two disadvantages of this approach: (1) the POSTed root part is not JSON, and (2) if we allow for parametrization all the parameter would also not be JSON (or will be URL-encoded JSON). 2. multipart/related This allows us to reuse existing serialization/representation for the root part as well as any parameters (if we decide to allow that). The message would like this -- MIME-Version: 1.0 Content-Type: multipart/related;boundary=MIME_boundary; type="application/json"; start="<123456@example.org>"; --MIME_boundary Content-Type: application/json Content-ID: <123456@example.org> {"pdp_uri" : "cid:abcdef@example.org"} --MIME_boundary Content-Type: application/zip Content-Transfer-Encoding: binary Content-ID: <abdcef@example.org> // binary octets for zip --MIME_boundary-- I prefer multipart related. What do others think? Is there a more appropriate media-type to use? Furthermore, if we decide to go with this proposal, I would like to suggest that we add another optional, immutable attribute to the AssemblyTemplate: pdpURI. This would point to the URI from which the template was created. This would allow for things such as discovery, cloning, registering the same PDP multiple times (perhaps with different customization), and debugging. Thanks. -Anish -- [1] https://tools.oasis-open.org/issues/browse/CAMP-3 [2] https://www.oasis-open.org/apps/org/workgroup/camp/download.php/49008/camp-spec-v1.1-wd09.doc [3] http://www.ietf.org/rfc/rfc2392.txt [4] http://tools.ietf.org/html/rfc2388 [5] http://tools.ietf.org/html/rfc2387--------------------------------------------------------------------- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]