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] creating things in CAMP


Comments inline . . .

On 3/20/2013 8:27 PM, Adrian Otto wrote:
On Mar 20, 2013, at 5:45 PM, Alex Heneveld <alex.heneveld@cloudsoftcorp.com>
 wrote:

I think we all agree you can POST a PDP to Platform to create an Assembly.

Yes, definitely.

As per Section 6.11 (WD08)

But:

0) Can you POST to an AssemblyTemplate (to create an Assembly) ?

Yes.

As per Section 6.12.


1) Can you POST to an ApplicationComponentTemplate (to create an ApplicationComponent) ?

Yes.

I don't see this in the spec anywhere. If you try this on the nCAMP POC you get back a 405, "Method Not Allowed".


2) Can you POST to a PlatformComponentTemplate (to create a PlatformComponent) ?

No. That must be done by the Platform Admin, and there is no expectation that the API handle that.

In my view there are two ways a PlatformComponent is created. For static PlatformComponents (like a free DB instance that is shared by trial users), the PC is created by some behind-the-scenes magic that CAMP is silent about. For dynamic PCs that are spun up for the sole use of an application, the PC is instantiated from the PCT as a part of the process of creating the Assembly.


And finally:

3) Do we say (in the spec) what the result of such a POST is? (Could (1) return an Assembly ?)

We should. That could be made more clear.

I'm not sure what isn't clear. Section 6.11 tells you that URL of the newly created Assembly Template will be supplied to the client in the Location header of the HTTP response. Section 6.123 tells you that the URL of the newly created Assembly will be supplied to the client in the Location header of the HTTP response.


4) If (1) and/or (2) is _permitted_ by the spec, is it permitted for a compliant implementation to refuse such requests (ie only support (0); or even to support only PDP-initiated deployments) ?

The subject of access control is beyond the scope of the current spec. We don't explicitly allow or prohibit it.

Sending a POST to an Application Component Template has nothing to do with access control - it's simply not defined in the spec.

For (0), I would expect any compliant CAMP implementation to return a 403 on an authz failure, but I don't think we need to document this as that is what HTTP defines.

My thinking had implicitly been that consumers would do (0) and *not* (1) or (2).  The AC's and PC's are created by the platform in response, and every instance is "owned" by an assembly.  And the PDP is a convenience for supplying potentially a bunch of ACT's, PCT's, and an AssemblyTemplate.

That seems less natural than allowing POST actions to any template resource to create an instance of it.

I would say that this feeling of unnaturalness stems from the fact that Application Components and Application Component Templates, as we currently define them, are somewhat unnatural. Although they exist as separate resources with their own URL, etc., they are completely contained by their Assembly or Assembly Template. You cannot have an Application Component Template without its containing Assembly Template and you cannot have an Application Component without its containing Assembly. Therefore, you cannot allow the creation of an independent Application Component outside the context of an Assembly - what Assembly would reference it?


My read now though is that (1) and (2) are permitted.  So you could post to an ACT and get an AC back, and if this ACT (say it was a WAR file) had a requirement for some PC (say something with a WAR_appserver capability), there would be a PC created (or perhaps re-used) and the WAR installed there.  All makes sense.  But could we end up with these things running without any Assembly ... and is that a problem?

That's not a problem as far as I'm concerned. I may want to create components that are used by multiple Assemblies. It would still be related to my Platform, but just not to any Assembly.

I've been thinking that we need to add to the definition of a PCT to surface this distinction between PCs that are dynamically created when the Assembly tree is instantiated and PCs that exist outside the lifecycle of a particular Assembly. It should be possible for a PCT to declare "I am a template for an existing PC and here is a Link to that PC".

It would be very helpful to know what people are thinking here!

I have been thinking about many of the same things, as evidenced by my last update to CAMP-30. Thanks for starting this discussion.

Adrian



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