<div dir="ltr"><div><div><br></div>Keystone also has a resource that provides changes since[1], the query parameter used is "since".<br><br>[1] <a href="http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-revoke-ext.html#list-revocation-events">http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-revoke-ext.html#list-revocation-events</a><br><br></div>Ciao, Brant<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 19, 2015 at 3:25 PM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 06/19/2015 05:07 AM, Chris Dent wrote:<br>
><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>
><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>
><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><br>
<br>
</div></div>I think that is a reasonable summation. My personal feeling is that if<br>
'changes-since' is strictly defined as the AND of 2 other standard<br>
filters, it's not feeling very relevant to recommend it existing. It's<br>
now just a 2nd way to do exactly the same thing, and all we can do is<br>
screw it up ("A man with one watch always knows what time it is. A man<br>
with two watches is never quite sure.").<br>
<br>
If it's left a little more vague of "for resources that you expect to be<br>
regularly polled, this can provide an interface to only show the<br>
consumer relevent resources. If you choose to implement this, you must<br>
document what criteria is used to return resources from the url." And<br>
allow the possibility that their might be different sensible definitions<br>
depending on the resource, I'm happier about it.<br>
<span class="im HOEnZb"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
</span><div class="HOEnZb"><div class="h5">__________________________________________________________________________<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>
</div></div></blockquote></div><br></div>