Re: [camp] CAMP PDP discussion notes

[Alex Heneveld <alex.heneveld@cloudsoftcorp.com>]

Thanks Ashok.  Responses inline.

On 23/05/2013 22:59, Ashok Malhotra wrote:

Hi Alex:
A couple of comments inline ...

All the best, Ashok

On 5/23/2013 5:03 PM, Alex Heneveld wrote:

- Alex to open an issue allowing AT's explicitly to refer to PCT's and A's to PC's, so you don't have to always go through an AC(T) (example a site which offers Wordpress blogs as PCT's -- ACT's would just be posts and data, it's the PCT's which are interesting)

To keep the model simple, perhaps all we need is to allow void components
with requirements

That's possible but smells like a hack which we can easily repair.  To me that makes the model simpler -- more consistent and easier to work with.

Could you give an example where typed components are useful?   I think this would help the discussion.

Sure.  Say I'm deploying two web apps A and B where A needs to access B and I want the connection to be secured with a certificate.  In my thinking, with component and requirement types (and assuming the types used below are defined elsewhere) this could all be expressed as:

    components:
     -
        id: A
        type: WAR
        content: { href: a.war }
        requirements: [ { type: JavaSystemProperty, key: a.required.service.url, value: "${B.url}" } ]
     -
        id: B
        type: WAR
        content: { href: b.war }
     -
        type: Certificate
        content: { href: b.cert }
        requirements:
         - { type: PresentedBy: fulfillment: B }
         - { type: TrustedBy, fulfillment: A }

This not bad.  (Not sure about the "${B.url}" syntax of course -- that's a discussion for another day!)

We could also support a "short-form" syntax where
- if "components" is a map rather than a list, the keys therein are interpreted as ids
- if "requirements" is a map, the keys therein are interpreted as types
- if "content" is a primitive, it is taken as an href
That's a little bit tedious to spell out in words but simple to implement and it makes a big difference to readability.  The above then becomes:

    components:
      A:
        type: WAR
        content: a.war
        requirements:
          JavaSystemProperties:
            a.required.service.url: "${B.url}"
      B:
        type: WAR
        content: b.war
      cert:
        type: Certificate
        content: b.cert
        requirements:
          PresentedBy: B
          TrustedBy: A

I can see people having fun writing this!

- people seem generally happy with DP as a bag of components each with requirements

So, stepping back for a minute.  My thinking is that introducing requirement types allows people to innovate in the types in more interesting and powerful ways without the DP structure getting in the way.  Without that, or something similar, I found myself fighting the DP (that's why I brought them in ... I'm always loathe to introduce a new concept!).

- nobody seems opposed to yaml anymore and some people strongly in favour

My concern is not with YAML but with allowing both JSON and YAML.
Early on we decided that we would not support both XML and JSON due to the added complexity
and picked JSON.  Let's use the same argument here and pick either YAML or JSON

Just YAML is fine by me.

--A