====================================
#openstack-marconi: marconi-api-http
====================================


Meeting started by kgriffs at 16:10:52 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/marconi_api_http/2013/marconi_api_http.2013-10-31-16.10.log.html
.



Meeting summary
---------------

* LINK: https://wiki.openstack.org/wiki/Marconi/specs/api/next
  (kgriffs, 16:10:58)
* Return an href for deleting all claimed messages with a single call
  (kgriffs, 16:11:28)
  * do not support bulk delete of claimed messages  (kgriffs, 16:21:26)

* Allow PUTing metadata when creating a queue  (kgriffs, 16:21:31)

* Set queue options for defaults, such as message and claim TTL.
  (kgriffs, 16:27:02)

* homedoc should return relative URIs or encode version in href-template
  (kgriffs, 16:30:56)
  * LINK: http://www.ietf.org/rfc/rfc1808.txt  (kgriffs, 16:36:56)
  * LINK: https://bugs.launchpad.net/marconi/+bug/1245656  (kgriffs,
    16:38:31)
  * fix href-template paths in home doc in v1.0; don't wait for 1.1
    (kgriffs, 16:39:27)

* 204 vs. 200 + empty array  (kgriffs, 16:44:17)
  * LINK: https://bugs.launchpad.net/marconi/+bug/1245656  (kgriffs,
    16:44:54)
  * ACTION: fvollero to take care of bug #1245656  (kgriffs, 16:45:21)
  * LINK:
    https://wiki.openstack.org/wiki/Marconi/specs/api/v1#List_Messages
    (kgriffs, 16:48:09)
  * return an empty array on listing options when no items are
    available, plan for v1.1  (kgriffs, 16:54:58)

* Consistency around response envelope for /messages vs /messages?ids
  (kgriffs, 16:55:17)

* Response envelopes in general - don't return raw arrays (to allow for
  extensions)  (kgriffs, 17:25:47)
  * encapsulate arrays in objects to make resource representations
    extensible  (kgriffs, 17:31:03)

* Return full URIs in location/content-location headers (rather than
  relative ones)  (kgriffs, 17:31:25)
  * Continue to return partial URIs  (kgriffs, 17:41:02)

* Is content-location header really necessary?  (kgriffs, 17:41:08)

* Polling model is based on the assumption of a "streaming" interaction
  model. Is there a place for a "point in time" listing model, where you
  don't always get a "next" href?  (kgriffs, 17:45:40)
  * revisit for v2 API  (kgriffs, 17:46:31)

* Query parameters are usually considered to be "optional", and yet
  DELETE queues/my-queue/messages requires an "ids" parameter. Some
  options:  (kgriffs, 17:47:50)



Meeting ended at 17:49:48 UTC.



Action items, by person
-----------------------

* fvollero
  * fvollero to take care of bug #1245656



People present (lines said)
---------------------------

* kgriffs (165)
* flaper87 (103)
* alcabrera (50)
* zyuan (50)
* fvollero (17)
* ametts (12)
* malini (5)
* cpallares (4)
* openstackgerrit (3)
* openstack (3)



Generated by `MeetBot`_ 0.1.4