On 21/11/12 18:19, Martyn Taylor wrote: > On 11/21/2012 12:40 PM, [email protected] wrote: >> On 21/11/12 12:49, Martyn Taylor wrote: >>> Please find Aeolus Tech Cabal initial meeting minutes below. >>> >>> Next weeks Agenda can be found here: >>> http://openetherpad.org/AeolusTechnicalCabal >>> >>> You must add items to the etherpad if they are to be discussed in next >>> Cabal meeting. Anyone wanting to add items to the Agenda then please do >>> so by 26/11/2012. This will give people a chance to do some >>> preparation. >>> >>> Next meeting 27/11/2012 >>> >> can we get a recording next time pretty please? :) > I'll see what we can do. Alternatively you could always attend the > meeting.
oh, and thanks - I assumed it was closed to members of the tech cabal only. marios >> marios >> >>> Regards >>> >>> Martyn >>> >>> >>> Aeolus Tech Cabal: 20/11/2012 >>> >>> >>> Attendees >>> >>> * Tomas Sedovic >>> * Martyn Taylor >>> * Jason Guiditta >>> * Scott Seago >>> * Eric Healms >>> * Michal Fojtik >>> * Greg Blomquist >>> * Jaramori Coufal >>> >>> >>> Agenda >>> >>> >>> Procedural Items >>> >>> *Meeting Format: Hugh will send format to the list before next Cabal >>> Meeting* >>> >>> * Meeting Time: >>> o 2pm Tuesday Recurring. >>> o 1 hour max. >>> o Items not covered will be raised in next meeting >>> * Awesome >>> o 1st Post: Martyn Taylor >>> o Respoibilities >>> + Ensure agenda is adequate >>> + Ensure meetings move forward. >>> * Secretary: >>> o Weekly rotation: Next: Greg Blomquist >>> o Responsibilites >>> + Take Minutes >>> + Distribute Minutes >>> >>> >>> Technical >>> >>> >>> API Resource Representation. >>> >>> 1. When shall we use full resource and minimal (link) resource >>> representation in the API? >>> 2. How should we allow client to access these resources? >>> >>> Martyn Proposed we represent full resources in all top level >>> collections. Sub resources will be represented as a collection (with >>> url) when one to many relationship is present. Sub resource collections >>> will include minimal resources. >>> >>> Scott agreed this could solve many of the issues we are currently facing >>> with the API and would be useful in the API. >>> >>> Greg mentioned that this could cause some issues with configure. But >>> will seek advice from Eck >>> >>> Cabal voted in favour of proposal. >>> >>> >>> Actions: >>> >>> * *Greg* will Confirm with Eck >>> * *Martyn* will send mail to list further explaining the proposal. >>> * *Martyn* will inform API contributers of changes. >>> >>> >>> Instance State Machine >>> >>> 1. How do we represent state changes in the API? Particularly for >>> instances, deployments and deployables. >>> >>> Michal spoke about using actions and links that represent state changes. >>> >>> It was agreed that this is not strictly RESTful. Discussion around pure >>> REST v usability started, but the Cabal came to no conclusion on the >>> matter. >>> >>> Michal advised us to take a look at the CIMI documentation >>> (http://dmtf.org/sites/default/files/standards/documents/DSP0263_1.0.1.pdf). >>> >>> Since the API resembles ours in many ways. >>> >>> >>> Actions: >>> >>> * CIMI investigation >>> * Further discussion on the list. >>> * Initial topic next meeting. (If unresolvable on list) >>> >>> >>> Outstanding Agenda Items >>> >>> 1. API versioning - Supporting for versioning the API (Not for >>> supporting multiple version) >>> 1. URL v HTTP Header (Server HTTP header?) >>> 2. e.g. >>> >>> http://docs.openstack.org/api/openstack-identity-service/2.0/content/Versions-d1e472.html#d8e186 >>> >>> >>> >>> 2. API Paging/Filtering/Sorting? >>> 1. >>> http://blog.apigee.com/detail/restful_api_design_can_your_api_give_developers_just_the_information >>> >>> >>> 3. API Race Conditions >>> 4. Handling Deltacloud exceptions in Deltacloud - What need to be done >>> to improve it.. >>> 5. Callbacks in Deltacloud - When, how and who :-) >>> >>> > >
