16:10:52 <kgriffs> #startmeeting marconi-api-http
16:10:53 <openstack> Meeting started Thu Oct 31 16:10:52 2013 UTC and is due to finish in 60 minutes.  The chair is kgriffs. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:10:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:10:56 <openstack> The meeting name has been set to 'marconi_api_http'
16:10:58 <kgriffs> #link https://wiki.openstack.org/wiki/Marconi/specs/api/next
16:11:28 <kgriffs> #topic Return an href for deleting all claimed messages with a single call
16:12:00 <alcabrera> Hmmm...
16:12:08 <alcabrera> That's a strange kind of pattern.
16:12:13 <alcabrera> It's almost like cancelling a claim.
16:12:18 <kgriffs> somebody was asking about this. Currently I don't think the bulk delete takes a claim ID
16:12:22 <alcabrera> Or grabbing a *right* to delete a set of messages.
16:12:36 <kgriffs> I guess the idea is you would process N messages, then do the delete
16:12:40 <kgriffs> but seems like an anti-pattern
16:12:47 <alcabrera> ahh
16:13:13 <alcabrera> I think that's an anti-pattern, given that it makes sense to grab one, delete one as it is completed.
16:13:15 <alcabrera> Also
16:13:18 <alcabrera> Crash conditions
16:13:26 <alcabrera> If you processed 1-5 of 10, but then crashed...
16:13:33 <alcabrera> How do others know you completed 1-5?
16:13:37 <flaper87> mmh, I'm not sure I like this idea
16:13:40 <alcabrera> Anti-pattern rationale ^^
16:13:53 <flaper87> I mean, why would you delete all claimed messages ?
16:13:53 <kgriffs> since if the worker crashes in the middle, that is N-p work items that would have to be rolled back.
16:14:06 <flaper87> I'd rather release them if I don't want to work on them anymore
16:15:16 <kgriffs> only reason to support this that I can see (and it is a thin reason at that) would be if you have tons of very tiny messages
16:15:28 <kgriffs> like stats or something
16:15:43 <kgriffs> but then, marconi is probably not the right tool for the job in that case?
16:16:07 <kgriffs> i mean, the advantage there would be batching up the deletes so they happen faster
16:16:20 <flaper87> agreed
16:16:26 <alcabrera> yeah. :/
16:16:46 <kgriffs> on the other-other hand, that could mostly be solved by the transport layer
16:17:03 <kgriffs> zmq, spdy/http2.0, websockets
16:17:17 <kgriffs> ok, so strike this one?
16:18:13 <alcabrera> +1
16:18:20 <alcabrera> for striking
16:18:26 <flaper87> striking +1
16:20:50 <flaper87> next ?
16:21:01 <kgriffs> sorry, taking notes
16:21:23 <flaper87> ok, sorry, didn't mean to push!
16:21:26 <kgriffs> #info do not support bulk delete of claimed messages
16:21:31 <kgriffs> #topic Allow PUTing metadata when creating a queue
16:21:47 <kgriffs> TBH, I can't remember where this came from
16:22:14 <kgriffs> we used to do this, but changed
16:22:31 <kgriffs> because we decided that mixing queue metadata and queue options in a single resource was ugly
16:22:38 <flaper87> I think the only advantage of that is to reduce the number of calls required to create a queue
16:22:40 <kgriffs> so we wanted to make them their own resources
16:22:42 <alcabrera> yup
16:22:49 <kgriffs> flaper87: right
16:22:56 <flaper87> however, what you said was our last thought
16:23:05 <flaper87> making them independent resources
16:23:08 <kgriffs> I suppose if we add, say, default message TTL we could have that directly on the queue resource
16:24:00 <kgriffs> http put https://marconi.example.com/v2/queues default_ttl:=300
16:24:09 <kgriffs> (or something like that)
16:25:02 <kgriffs> you might also put queue flavor as well (choose a shard type)
16:25:16 <kgriffs> anyway, I think we won't change this
16:25:26 <flaper87> I agree with you
16:25:27 <kgriffs> but we might add default options and stuff
16:25:37 <flaper87> also, metadata != queue properties
16:25:42 <kgriffs> something like default TTL - would that be a v1.1 or a v2 do you think?
16:25:47 <kgriffs> flaper87: +1
16:25:53 <flaper87> so, which should we support during queue's creation?
16:25:57 <flaper87> that will confuse users
16:26:02 <flaper87> and amke the api inconsistent
16:26:09 <flaper87> so, totally with you there! Lets strike this one
16:26:15 <kgriffs> ok.
16:26:22 <alcabrera> strike + 1
16:26:57 <kgriffs> I just added this one...
16:27:02 <kgriffs> #topic  Set queue options for defaults, such as message and claim TTL.
16:27:29 <kgriffs> TBH, I'm not sure how useful that is, since the clients will just stick in whatever
16:27:41 <kgriffs> only thing is I guess it would make the request body a tiny bit smaller
16:28:26 <flaper87> my only concern is that we'll have to have those properties available everytime a message gets in
16:28:46 <kgriffs> yes, we can cache them, but it will still be a little bit of a perf hit
16:29:04 <flaper87> and it'll require even more resources to the final user
16:29:35 <flaper87> like 'take queue caching under consideration when you buy the RAM'
16:29:36 <kgriffs> how about striking then, given clients can implement default behavior on their own
16:29:48 <alcabrera> kgriffs: +1 to that
16:29:50 <kgriffs> flaper87: true
16:29:55 <flaper87> kgriffs: +1
16:30:29 <kgriffs> ok, let me make notes
16:30:56 <kgriffs> #topic homedoc should return relative URIs or encode version in href-template
16:31:03 <kgriffs> see also: https://bugs.launchpad.net/marconi/+bug/1245656
16:31:17 <kgriffs> so, I view this as a typo in the spec and a bug in the implementation
16:31:59 <kgriffs> pedants will insist the v1 API is frozen, but I think we should fix this
16:32:10 <flaper87> +1 for relative urls
16:32:29 <flaper87> and +1 for encoded version of href-template
16:32:33 <flaper87> and +1 for fixing this
16:33:09 <kgriffs> ok. Any client that is trying to "follow it's nose", using hrefs from the home doc, is broken now anyway
16:33:09 <alcabrera> I'm in favor of getting this fixed sooner rather than later.
16:33:23 <alcabrera> Since the longer we leave it a broken state, the longer we'll encourage "bad" behavior.
16:33:50 <kgriffs> flaper87: fwiw, I discovered that "relative URI" is a misleading term
16:34:00 <flaper87> kgriffs: what's the right one?
16:34:07 * flaper87 is about to learn something new
16:34:16 <kgriffs> a "relative URI" as described by RFC really means "partial URI"
16:34:48 <kgriffs> using my term there, a "partial URI" can have either an *absolute* and *relative* path
16:34:48 <flaper87> alcabrera: kgriffs in addition, I need this to work to implement that client :D
16:34:55 <kgriffs> s/and/or
16:35:06 <kgriffs> so both of these are "partial" URIs:
16:35:17 <kgriffs> /queues/foo
16:35:19 <alcabrera> flaper87: yeah, keep the client coming! ;)
16:35:22 <kgriffs> queues/foo
16:35:43 <kgriffs> formally defined and "relative URIs"
16:36:02 <flaper87> kgriffs: mmh, interesting! I ignored that.
16:36:03 <kgriffs> s/and/as
16:36:36 <kgriffs> so, when you see someone say "relative URI" it may or may not mean the *path* in the URI is relative!
16:36:44 <ametts> Just read:  "so, I view this as a typo in the spec and a bug in the implementation"
16:36:51 <ametts> kgriffs should be a politician
16:36:56 <kgriffs> #link http://www.ietf.org/rfc/rfc1808.txt
16:37:05 <kgriffs> ametts: LOL
16:37:06 <ametts> Now we can change the API any time we want! :)
16:37:35 <kgriffs> ok so, any objections to fixing this in v1.0 ?
16:37:51 <kgriffs> the only danger is someone may have written a client that works around the bug
16:37:56 <kgriffs> and we will break their workaround
16:38:00 <alcabrera> none from me
16:38:01 <ametts> Not from me.  I think sooner than later is better too.
16:38:03 <malini> kgriffs: we really need this fixed in v1.0 :)
16:38:24 <kgriffs> any volunteers?
16:38:27 <ametts> Now I'm doubly-sure.  We don't want to incur the wrath of Malini.
16:38:28 <flaper87> v1.0
16:38:31 <kgriffs> #link https://bugs.launchpad.net/marconi/+bug/1245656
16:38:42 <flaper87> fvollero: cpallares ^ ?
16:38:54 <flaper87> maybe you guys wanna take that one
16:39:08 <flaper87> cpallares: you're already working on s/queues:// bug, aren't you?
16:39:18 <cpallares> yes
16:39:27 <kgriffs> #info fix href-template paths in home doc in v1.0; don't wait for 1.1
16:39:45 <flaper87> I think fvollero is not around but he was looking for a bug to fix
16:39:55 <flaper87> I'll ping him off-line and see if he wants to take it
16:40:02 <flaper87> otherwise, I guess I could take it
16:40:10 <cpallares> if he doesn't , I could!
16:40:15 <flaper87> cpallares: cool
16:40:17 <cpallares> It's just fixing the path right?
16:40:18 <flaper87> +1
16:40:31 <kgriffs> ok, whoever it is just assign yourself
16:40:38 <kgriffs> I will update the spec
16:40:54 <kgriffs> should be easy; just remove the '/' prefix
16:41:17 <kgriffs> oh, and write a test to ensure it can be combined
16:41:19 <fvollero> flaper87: i'm here
16:41:20 <flaper87> cpallares: yeah, you also have to build a car, an airplane and elaborate a new theory about the milky way
16:41:21 <kgriffs> let me note that
16:41:38 <cpallares> flaper87: haha don't mock me, for a beginner it sometimes feel like that :P
16:41:55 <flaper87> cpallares: hihihi!
16:41:59 <malini> kgriffs: what abt /v1 in some of the href-templates?
16:42:08 <flaper87> fvollero: so, I remember you're looking for a bug to fix
16:42:18 <flaper87> there's one that wouldn't take much of your time
16:42:18 <fvollero> flaper87: yep
16:42:24 <flaper87> fvollero: wanna squash it ?
16:42:30 <malini> kgriffs: like this one '"http://docs.openstack-marconi.org/rel/claim": {
16:42:30 <malini> "href-template": "/v1/queues/{queue_name}/claims{?limit}",
16:42:30 <malini> '
16:42:31 <fvollero> flaper87: ok.. .i'll give a try :)
16:42:43 <flaper87> fvollero: cool, assign yourself there!
16:42:51 <flaper87> and many thanks!
16:42:52 <fvollero> flaper87: i was backporting some stuff to puppet-ceilo
16:42:58 <fvollero> flaper87: let me finish it first
16:43:06 <flaper87> fvollero: yeah sure, no hurries
16:43:10 <kgriffs> fvollero:  thanks man!
16:43:21 <fvollero> kgriffs: Arrrgh :) I didn't look at it yet :)
16:43:50 <flaper87> fvollero: ametts will buy you some beers
16:43:55 <flaper87> fvollero: he told me that!
16:44:06 <kgriffs> ok, moving on
16:44:08 <fvollero> flaper87: lol ! Fair enough! ametts thanks a bunch :)
16:44:17 <kgriffs> #topic 204 vs. 200 + empty array
16:44:35 <ametts> I'll swap beers for code any day
16:44:36 <fvollero> kgriffs: link for rhia?
16:44:49 <kgriffs> link for the bug?
16:44:52 <fvollero> yeah
16:44:54 <kgriffs> https://bugs.launchpad.net/marconi/+bug/1245656
16:44:55 <fvollero> kgriffs: stupid keyboard
16:45:10 * flaper87 is leaning towards 200 + empty list here
16:45:12 <fvollero> kgriffs: I was referring to 204 vs 200 + []
16:45:21 <kgriffs> #action fvollero to take care of bug #1245656
16:45:24 <fvollero> flaper87: well, depend
16:45:27 <kgriffs> fvollero: oic
16:45:46 * ametts likes the empty list too.  He even saw this technique in an OReilly book recently.
16:45:49 <kgriffs> i don't have a link to a bug or anything, we are just walking through a list of feedback
16:45:54 <fvollero> ok
16:46:01 <alcabrera> I'm going to step out of this meeting to get heads down on the remaining sharding unit test failures.
16:46:12 <fvollero> kgriffs: for what we're using 204 usually ?
16:46:21 <ametts> Go alcabrera, go!
16:46:21 <kgriffs> so, while 204 isn't necessarily incorrect, and saves a few bytes on the wire, it is inconsistent with other OpenStack APIs
16:46:37 <kgriffs> and *may* make client implementations a tad bit easier
16:46:55 <kgriffs> fvollero: if there are no messages, we return 204 currently
16:46:55 <flaper87> kgriffs: damn, you're faster than me
16:47:03 <kgriffs> (Rather than an empty JSON array)
16:47:05 <flaper87> I was about to write the client thing
16:47:34 <flaper87> the other thing I like about the empty list is that it's more explicit
16:47:47 <flaper87> you see that and you know there are no messages
16:47:53 <flaper87> no need to check status code
16:47:57 <flaper87> etc
16:48:01 <ametts> flaper87: agreed
16:48:08 <fvollero> kgriffs: gotcha :)
16:48:09 <kgriffs> #link https://wiki.openstack.org/wiki/Marconi/specs/api/v1#List_Messages
16:48:15 <kgriffs> current behavior ^^
16:48:41 <fvollero> flaper87: usually no one should look at the API response :)
16:49:02 <openstackgerrit> Zhihao Yuan proposed a change to openstack/marconi: feat(shard): queue listing from multiple sources  https://review.openstack.org/53127
16:49:04 <kgriffs> ok, any objections to doing this in v1.1 ?
16:49:11 <zyuan> a trivial rebase
16:49:17 <flaper87> fvollero: ish, it depends on what the user is doing
16:49:21 <flaper87> but I agree
16:49:29 <flaper87> kgriffs: no objections from me
16:49:33 <zyuan> i did not follow
16:49:42 <zyuan> what's the resolution
16:50:15 <ametts> This will break existing clients.   Will there be too much legacy code by the time we get 1.1. out?
16:50:41 <kgriffs> zyuan: by "doing this" I mean switching to returning an empty array of messages and queues rather than 204
16:51:01 <ametts> Or I guess that's what API versioning is for.
16:51:04 <kgriffs> right
16:51:14 <kgriffs> v1 will still be available
16:51:25 <ametts> Okay.  I'm good, then.
16:51:29 <kgriffs> v1.0, I mean
16:51:29 <zyuan> i have no strong objection, but i don't see how can we benefit from this also
16:51:36 <kgriffs> should we also do this when claiming messages?
16:51:45 <kgriffs> if no messages to claim, return empty array?
16:51:52 <zyuan> it seems to be easier to use, but affect user's bandwidth
16:52:57 <flaper87> yeah, small tread-off betwen UX and bandwith, I guess
16:52:58 <fvollero> zyuan: well, user bandwidth in the order of 4 bytes
16:53:02 <kgriffs> zyuan: true, but we can mitigate that somewhat by using msgpack media type
16:53:18 <kgriffs> ok, let's do it
16:53:21 <flaper87> it'll give you more consistency, better API and easier integration
16:53:28 <zyuan> fvollero: more than that
16:53:33 <kgriffs> I think we have rough consensus
16:53:38 <zyuan> fvollero: you need hrefs as well
16:53:49 <kgriffs> (consensus on doing this in marconi)
16:53:50 <zyuan> otherwise it's even more incovient
16:54:07 <flaper87> kgriffs: +1 from me
16:54:58 <kgriffs> #info return an empty array on listing options when no items are available, plan for v1.1
16:55:17 <kgriffs> #topic Consistency around response envelope for /messages vs /messages?ids
16:56:07 <kgriffs> this would simplify client implementations
16:56:13 <kgriffs> and conceptually, I think it makes sense
16:56:31 <kgriffs> because both operations operate on the same resource, so you would expect the same representation to come back in each case IMO
16:56:34 <zyuan> i see no need so "consistency"
16:56:38 <zyuan> for*
16:56:48 <zyuan> because they are jsut different
16:56:55 <zyuan> and we showed how they are different
16:58:07 <zyuan> to make them look furtherly different, we can change endpoints name. but not response.
16:58:36 <kgriffs> I have a counterpoint to that argument
16:59:06 <kgriffs> to support API extensions, we will need to wrap those json arrays in objects
16:59:25 <zyuan> i don't see a need for API extension on message bulk get
16:59:26 <kgriffs> so you can have {"EXT-foo": {...}, "messages": []}
16:59:46 <zyuan> this is just an endpoint for... restful, only
16:59:59 <kgriffs> zyuan: the point of extensions is to allow 3rd-parties to customize the API with things we didn't think about or feel is outside the scope of the core project
17:00:17 <zyuan> kgriffs: 3rd can already do that on message listing
17:00:32 <zyuan> i'm jsut saying there is no need for message bulk geting
17:00:33 <kgriffs> my point is, if we do that, then it makes it easy to make the two response schemas consistent
17:00:34 <zyuan> the ids one
17:00:40 <zyuan> they are different
17:00:46 <kgriffs> since all you need is a "links" with and empty list
17:00:50 <zyuan> so there is no need for "consistency"
17:01:07 <flaper87> zyuan: could you ellaborate on why they are different?
17:01:19 <flaper87> elaborate*
17:01:24 <zyuan> one is listing, one is get multiple
17:01:52 <zyuan> ?ids is not an API filtering the first one
17:02:03 <zyuan> it's just another completely different API
17:02:12 <zyuan> and pretty much useless in marconi picture
17:02:39 <zyuan> for the most of time you want listing, without ?ids
17:02:42 <flaper87> thanks, we're on the same page there
17:03:17 <zyuan> they unfortuantely overloaded on names
17:03:26 <flaper87> they're conceptually different, however, I can see some value in making the response consistent, although there's no need for consistency.
17:03:28 <zyuan> but we just don't have an HTTP method call LIST
17:04:00 <zyuan> just think this:
17:04:10 <flaper87> but I'm leaning towards to keeping them as they are
17:04:13 <zyuan> which "links" you want to put in ?ids response?
17:04:20 <zyuan> i can not think of any
17:04:40 <zyuan> next? prev? lol
17:05:21 <flaper87> yeah, I agree with you there
17:05:29 <flaper87> but we can at least have { messages:{}}
17:05:38 <flaper87> but we can at least have { messages:[]}
17:06:06 <flaper87> but that won't make much sense, I guess.
17:06:12 * flaper87 is thinking outloud
17:06:19 <zyuan> then that furtherly confuse people
17:06:30 <zyuan> you see, even we defined their semnatics
17:06:42 <zyuan> people come to us and say "why they are inconsistent"
17:06:49 <zyuan> and if you make them even more similiar
17:06:57 <zyuan> hehe
17:07:14 <flaper87> heh
17:07:14 <zyuan> "why ids does not accept limit=?"
17:07:37 <zyuan> the best way to make different things different is just to name them differently
17:07:52 <zyuan> otherwise, i'm ok with removing ?ids GET
17:08:34 <flaper87> if we ever get there, that'd be v2 material
17:08:39 <flaper87> removing ?ids, that is!
17:08:55 <flaper87> anyway, I think we shouldn't make these 2 responses consistent
17:09:00 <flaper87> kgriffs: thoughts ?
17:10:13 <openstackgerrit> Alejandro Cabrera proposed a change to openstack/marconi: feat: connect sharding manager to control drivers  https://review.openstack.org/54605
17:10:38 <alcabrera> kgriffs, ametts, flaper87: There it is - shahrding manager core. ^^
17:10:46 * alcabrera catches up to everything
17:10:56 <flaper87> alcabrera: wb, thanks!
17:12:23 <alcabrera> phew, lots of consistency discussions.
17:12:38 * alcabrera waits for jenkins to sing
17:13:32 <alcabrera> oops, I forgot to wrap a test in 'requires_mongodb'
17:21:43 <kgriffs> flaper87: hmmm, I still think that querying the same resource should yield the same basic schema
17:21:49 <kgriffs> even if it is just {
17:21:54 <kgriffs> "messages": [] }
17:21:58 <kgriffs> instead of just []
17:22:23 <kgriffs> having a "links": [] may no be needed
17:22:38 <zyuan> so my suggestion is to split them into two resourses
17:22:41 <kgriffs> if we want to change the operation syntax so it is it's own resource, then they can be different
17:22:58 <zyuan> list move listing messages to /messages_list
17:23:05 <zyuan> like*
17:23:15 <zyuan> or remove ?ids
17:23:22 <zyuan> or move ?ids to another endpoint
17:23:38 <zyuan> or invent a concept of "message group"
17:24:00 <kgriffs> lots of options; let's just plan on creating a new resource in v2
17:24:03 <flaper87> mmh, in any case, this seem to be a v2 change, we're changing completely the response of one of our calls.
17:24:11 <flaper87> kgriffs: T_T
17:24:18 <kgriffs> LOL
17:24:58 <kgriffs> flaper87: I was just about to ask you if you agreed!
17:25:08 <flaper87> :P
17:25:13 <flaper87> that's my answer
17:25:16 <flaper87> :D
17:25:16 <kgriffs> OK, let's try to plow through a few more real quick
17:25:39 <kgriffs> alcabrera is out tomorrow, so I wanted to get as far as we can today
17:25:47 <kgriffs> #topic Response envelopes in general - don't return raw arrays (to allow for extensions)
17:26:01 <kgriffs> I alluded to this earlier
17:26:28 <kgriffs> when we just return [] there is no where to put a non-breaking extension document
17:26:44 <kgriffs> so, we should be returning {"things":[]} instead
17:27:11 <kgriffs> (or so the suggestion has been given)
17:27:53 <kgriffs> alcabrera: ping
17:28:39 <alcabrera> kgriffs: pong
17:28:51 * flaper87 will be out as well
17:28:54 <kgriffs> thoughts: ^^
17:28:55 <flaper87> it's holiday here
17:28:55 <openstackgerrit> Alejandro Cabrera proposed a change to openstack/marconi: feat: connect sharding manager to control drivers  https://review.openstack.org/54605
17:29:15 <alcabrera> kgriffs: +1 for the [] -> {}
17:29:28 <alcabrera> I agree with the extensibility argument
17:29:44 * flaper87 agress as well
17:29:53 <kgriffs> ok
17:29:55 <kgriffs> moving on
17:30:07 <kgriffs> wait.
17:30:55 <flaper87> agrees
17:30:57 <flaper87> *
17:31:03 <kgriffs> #info encapsulate arrays in objects to make resource representations extensible
17:31:25 <kgriffs> #topic Return full URIs in location/content-location headers (rather than relative ones)
17:31:55 <kgriffs> this tripped up Repose. I don't know if any other reverse proxies have a similar problem
17:31:56 <alcabrera> hmmm
17:31:58 <flaper87> I don't have a strong opinion here and TBH, not sure if I know which one is correct
17:32:06 <alcabrera> I'm with flaper87
17:32:27 <kgriffs> ok... only downside is slightly larger responses
17:32:40 <flaper87> what's the overall preference there?
17:32:47 <flaper87> I mean, what do people do normally?
17:32:53 <kgriffs> good question
17:33:30 <kgriffs> partial URIs are being standardized in the latest HTTP 1.1 RFC draft
17:33:56 <kgriffs> the goal of that effort is to formalize stuff that is already pretty common, iirc
17:34:06 <alcabrera> I wonder what HTTP 2.0 will do in this case...
17:34:06 <kgriffs> I know a lot of web servers handle them fine
17:34:33 <kgriffs> other openstack projects return full URIs afaik
17:35:04 <alcabrera> (Jenkins: Patch Set 7: Works for me) - re: sharding manager (w0000t)
17:35:05 <flaper87> if latest HTTP RFC uses partial URIs, I'd say we should use them and let not-standarized services burn in hell!
17:35:08 <flaper87> muahahahahahahahhaha
17:35:11 * alcabrera returns to topic
17:35:15 <kgriffs> LOL
17:35:23 <alcabrera> lol
17:35:49 <kgriffs> client URI/HTTP libraries handle them fine, don't they?
17:36:23 * flaper87 calls python-request's phone number and asks that
17:36:40 <flaper87> not sure if it speaks english, though. :D
17:36:51 * flaper87 should have a webcam in his place
17:36:52 <kgriffs> i mean, if I give you a "base" URI and a "relative" AKA "partial" URI, the library should just do the right thing
17:37:08 <flaper87> kgriffs: yeah, correct
17:37:23 <flaper87> I know python-request sticks to the RFC
17:37:23 <alcabrera> I think by forcing absolute URIs, we impose a subtle constraint/difficulty.
17:37:32 <alcabrera> That being
17:37:40 <alcabrera> If someone wants to implement a client-side proxy
17:37:43 <flaper87> I'm not sure about this specific case, though!
17:37:47 <alcabrera> They'd have to manually split content location each time.
17:37:56 <alcabrera> Whereas if we stick to relative/partial
17:38:04 <kgriffs> TBH, I don't know why Repose is trying to parse those headers in the first place
17:38:05 <flaper87> but hey, if that's what the standard says, I think we should stick to that
17:38:09 <alcabrera> The client-side proxy can just use base + partial.
17:38:11 <kgriffs> (rather than just pass-through)
17:38:31 * flaper87 votes for partial URIs
17:39:40 <alcabrera> +1 for partials
17:40:00 <kgriffs> ok, cool
17:40:15 <kgriffs> I think repose has a bug or something to fix this anyway
17:40:40 <kgriffs> and other proxies don't care AFAIK
17:40:51 <kgriffs> Just a few more!
17:41:02 <kgriffs> #info Continue to return partial URIs
17:41:03 <alcabrera> kk
17:41:08 <kgriffs> #topic Is content-location header really necessary?
17:41:17 <kgriffs> I did some reading about this
17:41:58 <kgriffs> it is really only helpful if you have alternate representations of a resource that can be accessed using a different path vs. specifying the media type in Accept
17:42:15 <kgriffs> example:
17:42:49 <kgriffs> client requests /queues with Accept: application/json
17:42:58 <kgriffs> then the server could respond with
17:43:30 <kgriffs> content-location: /queues.json
17:43:49 <kgriffs> Personally, I think the whole blah.json thing is silly
17:44:04 <kgriffs> so, I don't think we need to be setting this header
17:44:05 <alcabrera> I don;t like that X.format, either. :x
17:45:02 <kgriffs> ok, how about no longer setting that header in v1.1
17:45:10 <kgriffs> save a few bytes, and it isn't useful
17:45:21 <flaper87> yeah
17:45:24 <alcabrera> +1
17:45:27 <flaper87> +1
17:45:40 <kgriffs> #topic 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?
17:45:52 <kgriffs> This a big one, and would be for v2.0 anyway
17:45:58 <kgriffs> so I'd like to discuss it later
17:46:31 <kgriffs> #info revisit for v2 API
17:46:44 <flaper87> yeah and we'll also have a notification session during the design summit
17:46:53 <flaper87> I'd discuss this after the summit
17:47:24 <alcabrera> +1 for postponed discussion. I'd say we need for thoughts on that.
17:47:27 <alcabrera> also - v2.0
17:47:30 <alcabrera> It can wait. :DF
17:47:32 <alcabrera> :D
17:47:50 <kgriffs> #topic Query parameters are usually considered to be "optional", and yet DELETE queues/my-queue/messages requires an "ids" parameter. Some options:
17:48:01 <kgriffs> So, I think we can revisit this in v2 as well
17:48:25 <zyuan> hehe
17:48:34 <zyuan> "consistency" problem again
17:48:40 <kgriffs> right
17:48:47 <zyuan> if user don't understand overloading
17:49:02 <zyuan> then we disambigulate them
17:49:07 <flaper87> right
17:49:14 <kgriffs> I made a note to that affect (one of the options)
17:49:15 <zyuan> that's *the* way to solve problem like this
17:49:35 <kgriffs> ok, that's it!
17:49:42 <kgriffs> thanks for hanging in there everyone!
17:49:48 <kgriffs> #endmeeting