<div dir="ltr"><div>Hi, stackers</div><div><br></div>Since now we have merged filtering guideline[1], is that said we should implement this feature according this guideline? like this:<div><br></div><div><font face="arial, helvetica, sans-serif"><b>"<span class="pln" style="color:rgb(0,0,0);white-space:pre">GET </span><span class="pun" style="color:rgb(102,102,0);white-space:pre">/</span><span class="pln" style="color:rgb(0,0,0);white-space:pre">app</span><span class="pun" style="color:rgb(102,102,0);white-space:pre">/</span><span class="pln" style="color:rgb(0,0,0);white-space:pre">items</span><span class="pun" style="color:rgb(102,102,0);white-space:pre">?</span><span class="pln" style="color:rgb(0,0,0);white-space:pre">f_updated_at</span>=gte:some_timestamp"</b></font></div><div><font face="arial, helvetica, sans-serif"><b><br></b></font></div><div><font face="arial, helvetica, sans-serif">Do we have reached a consensus about this?</font></div><div><div class="gmail_extra"><br><div class="gmail_quote">2015-06-19 17:07 GMT+08:00 Chris Dent <span dir="ltr"><<a href="mailto:chdent@redhat.com" target="_blank">chdent@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
There's an open question in the API-WG on whether to formalize or<br>
otherwise enshrine the concept of a "changes-since" query parameter<br>
on collection oriented resources across the projects. The original<br>
source of this concept is from Nova's API:<br>
<br>
<a href="http://docs.openstack.org/developer/nova/v2/polling_changes-since_parameter.html" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/nova/v2/polling_changes-since_parameter.html</a><br>
<br>
There are arguments for and against but we've been unable to reach a<br>
consensus so the agreed next step was to bring the issue to the<br>
mailing list so more people can hash it out and provide their input.<br>
The hope is that concerns or constraints that those in the group<br>
are not aware of will be revealed and a better decision will be<br>
reached.<br>
<br>
The basic idea of "changes-since" is that it can be used as a way to<br>
signal that the requestor is doing some polling and would like to<br>
ask "Give me stuff that has changed since the last time I checked".<br>
As I understand it, for the current implementations (in Nova and<br>
Glance) this means "including stuff that has been deleted". Repeated<br>
requests to the resource with a "changes-since" parameter gives a<br>
running report on the evolving state of the resource. This is intended<br>
to allow "efficient polling"[0].<br>
<br>
The pro camp on this likes it because this is very useful and quite<br>
humane: The requestor doesn't need to know the details of how the<br>
query is is implemented under the hood. That is, if there are<br>
several timestamps associated with the singular resources in the<br>
collection which of those are used for time comparison and which<br>
attributes (such as "state" with a value of "deleted") are used to<br>
determine if a singular resource is included. The service gets to<br>
decide these things and in order for "efficient polling" to actually<br>
be achieved it needs to do in order to make effective queries of the<br>
data store.<br>
<br>
The con camp doesn't like it because it introduces magic, ambiguity<br>
and inconsistency into the API (when viewed from a cross-project<br>
perspective) and one of the defining goals of the working group is<br>
to slowly guide things to some measure of consistency. The<br>
alternate approach is to formulate a fairly rigorous query system<br>
for both filtering[1] and sorting[2] and use that to specify<br>
explicit queries that state "I want resources that are newer than time<br>
X in timestamp attribute 'updated_at' _and_ have attribute 'state'<br>
that is one of 'foo', 'bar' or 'baz'".<br>
<br>
(I hope I have represented the two camps properly here and not<br>
introduced any bias. Myself I'm completely on the fence. If you<br>
think I've misrepresented the state of things please post a<br>
clarifying response.)<br>
<br>
The questions come down to:<br>
<br>
* Are there additional relevant pros and cons for the two proposals?<br>
* Are there additional proposals which can address the shortcomings<br>
in either?<br>
<br>
Thanks for your input.<br>
<br>
[0] Please try to refrain from responses on the line of "ha!<br>
efficiency! that's hilarious!" and "ZOMG, polling, that's so<br>
last century". Everybody knows this already and it's not<br>
germane to the immediate concerns. We'll get to a fully message<br>
driven architecture next week. This week we're still working<br>
with what we've got.<br>
[1] filtering guideline proposal<br>
<a href="https://review.openstack.org/#/c/177468/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/177468/</a><br>
[2] sorting guideline proposal<br>
<a href="https://review.openstack.org/#/c/145579/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/145579/</a><span class="HOEnZb"><font color="#888888"><br>
-- <br>
Chris Dent tw:@anticdent freenode:cdent<br>
<a href="https://tank.peermore.com/tanks/cdent" rel="noreferrer" target="_blank">https://tank.peermore.com/tanks/cdent</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><pre>Best Wishes For You!</pre></div>
</div></div></div>