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


>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.

 

 

Wouldn’t the “you [POST]” in that case just be the platform admin – i.e. the only difference here between posting to a PlatformComponentTemplate vs to an ApplicationComponentTemplate is an access right, everything being otherwise equal?

 

Also could it be that when deploying an application over a platform that has some pre-existing PCTs, you may need to reconfigure a platform component e.g. by re-generating it  from its template, with the right parameters? (assuming the platform admin let you do that)

 

Just making sure we don’t introduce unwarranted restrictions…

 

-jacques

 

From: camp@lists.oasis-open.org [mailto:camp@lists.oasis-open.org] On Behalf Of Adrian Otto
Sent: Wednesday, March 20, 2013 8:27 PM
To: camp@lists.oasis-open.org
Subject: Re: [camp] creating things in CAMP

 

Alex,



On Mar 20, 2013, at 5:45 PM, Alex Heneveld <alex.heneveld@cloudsoftcorp.com>

 wrote:



Hi folks,



There was discussion today about POSTing to Templates to create instances.  There seem to be a few different ideas on how this would work.  I wanted to canvas opinion before opening an issue (if indeed we need one).



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

 

Yes, definitely.



But:



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

 

Yes.



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

 

Yes.



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.



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.



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.



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.



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.



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]