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? :) 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 :-) > >
