Re: [camp] CAMP PDP discussion notes

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