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

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:

2pm Tuesday Recurring.
1 hour max.
Items not covered will be raised in next meeting

Awesome

1st Post: Martyn Taylor
Respoibilities

Ensure agenda is adequate
Ensure meetings move forward.

Secretary:

Weekly rotation: Next: Greg Blomquist
Responsibilites

Take Minutes
Distribute Minutes

Technical

API Resource Representation.

When shall we use full resource and minimal (link) resource representation in the API?
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

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

API versioning - Supporting for versioning the API (Not for supporting multiple version)

URL v HTTP Header (Server HTTP header?)
e.g. http://docs.openstack.org/api/openstack-identity-service/2.0/content/Versions-d1e472.html#d8e186

API Paging/Filtering/Sorting?

http://blog.apigee.com/detail/restful_api_design_can_your_api_give_developers_just_the_information

API Race Conditions
Handling Deltacloud exceptions in Deltacloud - What need to be done to improve it..
Callbacks in Deltacloud - When, how and who :-)