Re: [openstack-dev] [api] [all] To changes-since or not to changes-since
On Aug 9, 2015, at 11:03 PM, hao wang sxmatch1...@gmail.commailto:sxmatch1...@gmail.com wrote: Hi, stackers Since now we have merged filtering guideline[1], is that said we should implement this feature according this guideline? like this: GET /app/items?f_updated_at=gte:some_timestamp Do we have reached a consensus about this? You’ll definitely want to drop the “f_” prefix from your filter name, see the about-to-be-merged guideline No project uses f_ prefix in filter params [1]. Everett [1] https://review.openstack.org/#/c/198547/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] [all] To changes-since or not to changes-since
Haha, thanks Everett, you're totally right. Anyway, with or without f_, I want to ensure we will use updated_at =gte:some_timestamp like guideline said, or use changes-since= some_timestamp. Since I think this function it's useful to query resources and we should introduce it into projects(some projects already have it.). 2015-08-11 6:34 GMT+08:00 Everett Toews everett.to...@rackspace.com: On Aug 9, 2015, at 11:03 PM, hao wang sxmatch1...@gmail.com wrote: Hi, stackers Since now we have merged filtering guideline[1], is that said we should implement this feature according this guideline? like this: *GET /app/items?f_updated_at=gte:some_timestamp* Do we have reached a consensus about this? You’ll definitely want to drop the “f_” prefix from your filter name, see the about-to-be-merged guideline No project uses f_ prefix in filter params [1]. Everett [1] https://review.openstack.org/#/c/198547/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best Wishes For You! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] [all] To changes-since or not to changes-since
GET /app/items?f_updated_at=gte:some_timestamp I guess this should only return existing entries in a collection, while the proposition was to add deleted entries to the result too (if we use changes_since). More like a delta, than simple filtering. -- Kirill Zaitsev Murano team Software Engineer Mirantis, Inc On 10 Aug 2015 at 07:10:23, hao wang (sxmatch1...@gmail.com) wrote: Hi, stackers Since now we have merged filtering guideline[1], is that said we should implement this feature according this guideline? like this: GET /app/items?f_updated_at=gte:some_timestamp Do we have reached a consensus about this? 2015-06-19 17:07 GMT+08:00 Chris Dent chd...@redhat.com: There's an open question in the API-WG on whether to formalize or otherwise enshrine the concept of a changes-since query parameter on collection oriented resources across the projects. The original source of this concept is from Nova's API: http://docs.openstack.org/developer/nova/v2/polling_changes-since_parameter.html There are arguments for and against but we've been unable to reach a consensus so the agreed next step was to bring the issue to the mailing list so more people can hash it out and provide their input. The hope is that concerns or constraints that those in the group are not aware of will be revealed and a better decision will be reached. The basic idea of changes-since is that it can be used as a way to signal that the requestor is doing some polling and would like to ask Give me stuff that has changed since the last time I checked. As I understand it, for the current implementations (in Nova and Glance) this means including stuff that has been deleted. Repeated requests to the resource with a changes-since parameter gives a running report on the evolving state of the resource. This is intended to allow efficient polling[0]. The pro camp on this likes it because this is very useful and quite humane: The requestor doesn't need to know the details of how the query is is implemented under the hood. That is, if there are several timestamps associated with the singular resources in the collection which of those are used for time comparison and which attributes (such as state with a value of deleted) are used to determine if a singular resource is included. The service gets to decide these things and in order for efficient polling to actually be achieved it needs to do in order to make effective queries of the data store. The con camp doesn't like it because it introduces magic, ambiguity and inconsistency into the API (when viewed from a cross-project perspective) and one of the defining goals of the working group is to slowly guide things to some measure of consistency. The alternate approach is to formulate a fairly rigorous query system for both filtering[1] and sorting[2] and use that to specify explicit queries that state I want resources that are newer than time X in timestamp attribute 'updated_at' _and_ have attribute 'state' that is one of 'foo', 'bar' or 'baz'. (I hope I have represented the two camps properly here and not introduced any bias. Myself I'm completely on the fence. If you think I've misrepresented the state of things please post a clarifying response.) The questions come down to: * Are there additional relevant pros and cons for the two proposals? * Are there additional proposals which can address the shortcomings in either? Thanks for your input. [0] Please try to refrain from responses on the line of ha! efficiency! that's hilarious! and ZOMG, polling, that's so last century. Everybody knows this already and it's not germane to the immediate concerns. We'll get to a fully message driven architecture next week. This week we're still working with what we've got. [1] filtering guideline proposal https://review.openstack.org/#/c/177468/ [2] sorting guideline proposal https://review.openstack.org/#/c/145579/ -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best Wishes For You! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] [all] To changes-since or not to changes-since
Hi, stackers Since now we have merged filtering guideline[1], is that said we should implement this feature according this guideline? like this: *GET /app/items?f_updated_at=gte:some_timestamp* Do we have reached a consensus about this? 2015-06-19 17:07 GMT+08:00 Chris Dent chd...@redhat.com: There's an open question in the API-WG on whether to formalize or otherwise enshrine the concept of a changes-since query parameter on collection oriented resources across the projects. The original source of this concept is from Nova's API: http://docs.openstack.org/developer/nova/v2/polling_changes-since_parameter.html There are arguments for and against but we've been unable to reach a consensus so the agreed next step was to bring the issue to the mailing list so more people can hash it out and provide their input. The hope is that concerns or constraints that those in the group are not aware of will be revealed and a better decision will be reached. The basic idea of changes-since is that it can be used as a way to signal that the requestor is doing some polling and would like to ask Give me stuff that has changed since the last time I checked. As I understand it, for the current implementations (in Nova and Glance) this means including stuff that has been deleted. Repeated requests to the resource with a changes-since parameter gives a running report on the evolving state of the resource. This is intended to allow efficient polling[0]. The pro camp on this likes it because this is very useful and quite humane: The requestor doesn't need to know the details of how the query is is implemented under the hood. That is, if there are several timestamps associated with the singular resources in the collection which of those are used for time comparison and which attributes (such as state with a value of deleted) are used to determine if a singular resource is included. The service gets to decide these things and in order for efficient polling to actually be achieved it needs to do in order to make effective queries of the data store. The con camp doesn't like it because it introduces magic, ambiguity and inconsistency into the API (when viewed from a cross-project perspective) and one of the defining goals of the working group is to slowly guide things to some measure of consistency. The alternate approach is to formulate a fairly rigorous query system for both filtering[1] and sorting[2] and use that to specify explicit queries that state I want resources that are newer than time X in timestamp attribute 'updated_at' _and_ have attribute 'state' that is one of 'foo', 'bar' or 'baz'. (I hope I have represented the two camps properly here and not introduced any bias. Myself I'm completely on the fence. If you think I've misrepresented the state of things please post a clarifying response.) The questions come down to: * Are there additional relevant pros and cons for the two proposals? * Are there additional proposals which can address the shortcomings in either? Thanks for your input. [0] Please try to refrain from responses on the line of ha! efficiency! that's hilarious! and ZOMG, polling, that's so last century. Everybody knows this already and it's not germane to the immediate concerns. We'll get to a fully message driven architecture next week. This week we're still working with what we've got. [1] filtering guideline proposal https://review.openstack.org/#/c/177468/ [2] sorting guideline proposal https://review.openstack.org/#/c/145579/ -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best Wishes For You! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] [all] To changes-since or not to changes-since
Keystone also has a resource that provides changes since[1], the query parameter used is since. [1] http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-revoke-ext.html#list-revocation-events Ciao, Brant On Fri, Jun 19, 2015 at 3:25 PM, Sean Dague s...@dague.net wrote: On 06/19/2015 05:07 AM, Chris Dent wrote: There's an open question in the API-WG on whether to formalize or otherwise enshrine the concept of a changes-since query parameter on collection oriented resources across the projects. The original source of this concept is from Nova's API: http://docs.openstack.org/developer/nova/v2/polling_changes-since_parameter.html There are arguments for and against but we've been unable to reach a consensus so the agreed next step was to bring the issue to the mailing list so more people can hash it out and provide their input. The hope is that concerns or constraints that those in the group are not aware of will be revealed and a better decision will be reached. The basic idea of changes-since is that it can be used as a way to signal that the requestor is doing some polling and would like to ask Give me stuff that has changed since the last time I checked. As I understand it, for the current implementations (in Nova and Glance) this means including stuff that has been deleted. Repeated requests to the resource with a changes-since parameter gives a running report on the evolving state of the resource. This is intended to allow efficient polling[0]. The pro camp on this likes it because this is very useful and quite humane: The requestor doesn't need to know the details of how the query is is implemented under the hood. That is, if there are several timestamps associated with the singular resources in the collection which of those are used for time comparison and which attributes (such as state with a value of deleted) are used to determine if a singular resource is included. The service gets to decide these things and in order for efficient polling to actually be achieved it needs to do in order to make effective queries of the data store. The con camp doesn't like it because it introduces magic, ambiguity and inconsistency into the API (when viewed from a cross-project perspective) and one of the defining goals of the working group is to slowly guide things to some measure of consistency. The alternate approach is to formulate a fairly rigorous query system for both filtering[1] and sorting[2] and use that to specify explicit queries that state I want resources that are newer than time X in timestamp attribute 'updated_at' _and_ have attribute 'state' that is one of 'foo', 'bar' or 'baz'. (I hope I have represented the two camps properly here and not introduced any bias. Myself I'm completely on the fence. If you think I've misrepresented the state of things please post a clarifying response.) The questions come down to: * Are there additional relevant pros and cons for the two proposals? * Are there additional proposals which can address the shortcomings in either? Thanks for your input. [0] Please try to refrain from responses on the line of ha! efficiency! that's hilarious! and ZOMG, polling, that's so last century. Everybody knows this already and it's not germane to the immediate concerns. We'll get to a fully message driven architecture next week. This week we're still working with what we've got. [1] filtering guideline proposal https://review.openstack.org/#/c/177468/ [2] sorting guideline proposal https://review.openstack.org/#/c/145579/ I think that is a reasonable summation. My personal feeling is that if 'changes-since' is strictly defined as the AND of 2 other standard filters, it's not feeling very relevant to recommend it existing. It's now just a 2nd way to do exactly the same thing, and all we can do is screw it up (A man with one watch always knows what time it is. A man with two watches is never quite sure.). If it's left a little more vague of for resources that you expect to be regularly polled, this can provide an interface to only show the consumer relevent resources. If you choose to implement this, you must document what criteria is used to return resources from the url. And allow the possibility that their might be different sensible definitions depending on the resource, I'm happier about it. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [api] [all] To changes-since or not to changes-since
From: Chris Dent chd...@redhat.com Sent: Friday, June 19, 2015 4:07 AM To: OpenStack-dev@lists.openstack.org Subject: [openstack-dev] [api] [all] To changes-since or not to changes-since There's an open question in the API-WG on whether to formalize or otherwise enshrine the concept of a changes-since query parameter on collection oriented resources across the projects. The original source of this concept is from Nova's API: http://docs.openstack.org/developer/nova/v2/polling_changes-since_parameter.html There are arguments for and against but we've been unable to reach a consensus so the agreed next step was to bring the issue to the mailing list so more people can hash it out and provide their input. The hope is that concerns or constraints that those in the group are not aware of will be revealed and a better decision will be reached. The basic idea of changes-since is that it can be used as a way to signal that the requestor is doing some polling and would like to ask Give me stuff that has changed since the last time I checked. As I understand it, for the current implementations (in Nova and Glance) this means including stuff that has been deleted. Repeated requests to the resource with a changes-since parameter gives a running report on the evolving state of the resource. This is intended to allow efficient polling[0]. The pro camp on this likes it because this is very useful and quite humane: The requestor doesn't need to know the details of how the query is is implemented under the hood. That is, if there are several timestamps associated with the singular resources in the collection which of those are used for time comparison and which attributes (such as state with a value of deleted) are used to determine if a singular resource is included. The service gets to decide these things and in order for efficient polling to actually be achieved it needs to do in order to make effective queries of the data store. The con camp doesn't like it because it introduces magic, ambiguity and inconsistency into the API (when viewed from a cross-project perspective) and one of the defining goals of the working group is to slowly guide things to some measure of consistency. The alternate approach is to formulate a fairly rigorous query system for both filtering[1] and sorting[2] and use that to specify explicit queries that state I want resources that are newer than time X in timestamp attribute 'updated_at' _and_ have attribute 'state' that is one of 'foo', 'bar' or 'baz'. I am wondering what are the reasons that changes-since seems to introduce magic, ambiguity and inconsistency into the API? Could this be addressed by requiring each service to precisely define what resources would be returned in response to the changes-since query? If each service defines this contract then there should not be any ambiguity on what resources to expect in the response of the query. That said, we may need to precisely define semantics of what it means to correctly implement this feature. For instance, could we define that the set of resources once returned by a particular timestamp in the query would be guaranteed to remain same for subsequent executions of the query (idempotency argument)? This may be difficult to ensure in systems that may be built around providing eventual guarantees. - Devdatta __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] [all] To changes-since or not to changes-since
On 6/19/15, 14:39, Ian Cordasco ian.corda...@rackspace.com wrote: On 6/19/15, 14:26, Kevin L. Mitchell kevin.mitch...@rackspace.com wrote: On Fri, 2015-06-19 at 10:07 +0100, Chris Dent wrote: * Are there additional relevant pros and cons for the two proposals? * Are there additional proposals which can address the shortcomings in either? On the latter question, would using the If-Modified-Since header[1] make any sense as a possible solution? That at least would be a standard HTTP convention for this sort of thing, and tends to match up with the semantics of a changes-since query parameter. First, please use the updated RFC references (https://tools.ietf.org/html/rfc7232#section-3.3) If-Modified-Since does not. That's meant for entire resources. In other words, let's say you're listing images in Glance and you do GET /v2/images And your response has HTTP/1.1 200 OK Last-Modified: some_last_modified_value In the headers, when you do GET /v2/images If-Modified-Since: some_last_modified_value Then you should either get a: HTTP/1.1 204 No Content Or HTTP/1.1 200 OK Last-Modified: new_last_modified_value (all of the images you saw before) In other words, If-Modified-Since is meant purely for the state of the resource. It's main purpose is when used in conjunction with caching. That said, changes-since is more of a delta. If you need an analogy, think of it as an equivalent to $ git log 2015.1.0..stable/kilo It's just the deltas after a certain timestamp. Also, for what it's worth, I used to think If-Modified-Since was what you thought it was, but I found out how woefully wrong I was. It's not exactly intuitive, but you can toy with it via the GitHub API. Their /users and /repos resources will give you ETag and Last-Modified information. If you wait a little long enough for it to change and use either of those values to make a request, you'll get all of it again, from the beginning. Cheers, Ian __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] [all] To changes-since or not to changes-since
On 06/19/2015 04:03 PM, Ian Cordasco wrote: On 6/19/15, 14:39, Ian Cordasco ian.corda...@rackspace.com wrote: On 6/19/15, 14:26, Kevin L. Mitchell kevin.mitch...@rackspace.com wrote: On Fri, 2015-06-19 at 10:07 +0100, Chris Dent wrote: * Are there additional relevant pros and cons for the two proposals? * Are there additional proposals which can address the shortcomings in either? On the latter question, would using the If-Modified-Since header[1] make any sense as a possible solution? That at least would be a standard HTTP convention for this sort of thing, and tends to match up with the semantics of a changes-since query parameter. First, please use the updated RFC references (https://tools.ietf.org/html/rfc7232#section-3.3) If-Modified-Since does not. That's meant for entire resources. In other words, let's say you're listing images in Glance and you do GET /v2/images And your response has HTTP/1.1 200 OK Last-Modified: some_last_modified_value In the headers, when you do GET /v2/images If-Modified-Since: some_last_modified_value Then you should either get a: HTTP/1.1 204 No Content Or HTTP/1.1 200 OK Last-Modified: new_last_modified_value (all of the images you saw before) In other words, If-Modified-Since is meant purely for the state of the resource. It's main purpose is when used in conjunction with caching. That said, changes-since is more of a delta. If you need an analogy, think of it as an equivalent to $ git log 2015.1.0..stable/kilo It's just the deltas after a certain timestamp. Also, for what it's worth, I used to think If-Modified-Since was what you thought it was, but I found out how woefully wrong I was. It's not exactly intuitive, but you can toy with it via the GitHub API. Their /users and /repos resources will give you ETag and Last-Modified information. If you wait a little long enough for it to change and use either of those values to make a request, you'll get all of it again, from the beginning. Right, it's the difference between the transport protocol semantics, and the application. Standard HTTP headers are about the transport protocol of HTTP, and do not care about your application. Here we're asking something about the application. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] [all] To changes-since or not to changes-since
On 06/19/2015 05:07 AM, Chris Dent wrote: There's an open question in the API-WG on whether to formalize or otherwise enshrine the concept of a changes-since query parameter on collection oriented resources across the projects. The original source of this concept is from Nova's API: http://docs.openstack.org/developer/nova/v2/polling_changes-since_parameter.html There are arguments for and against but we've been unable to reach a consensus so the agreed next step was to bring the issue to the mailing list so more people can hash it out and provide their input. The hope is that concerns or constraints that those in the group are not aware of will be revealed and a better decision will be reached. The basic idea of changes-since is that it can be used as a way to signal that the requestor is doing some polling and would like to ask Give me stuff that has changed since the last time I checked. As I understand it, for the current implementations (in Nova and Glance) this means including stuff that has been deleted. Repeated requests to the resource with a changes-since parameter gives a running report on the evolving state of the resource. This is intended to allow efficient polling[0]. The pro camp on this likes it because this is very useful and quite humane: The requestor doesn't need to know the details of how the query is is implemented under the hood. That is, if there are several timestamps associated with the singular resources in the collection which of those are used for time comparison and which attributes (such as state with a value of deleted) are used to determine if a singular resource is included. The service gets to decide these things and in order for efficient polling to actually be achieved it needs to do in order to make effective queries of the data store. The con camp doesn't like it because it introduces magic, ambiguity and inconsistency into the API (when viewed from a cross-project perspective) and one of the defining goals of the working group is to slowly guide things to some measure of consistency. The alternate approach is to formulate a fairly rigorous query system for both filtering[1] and sorting[2] and use that to specify explicit queries that state I want resources that are newer than time X in timestamp attribute 'updated_at' _and_ have attribute 'state' that is one of 'foo', 'bar' or 'baz'. (I hope I have represented the two camps properly here and not introduced any bias. Myself I'm completely on the fence. If you think I've misrepresented the state of things please post a clarifying response.) The questions come down to: * Are there additional relevant pros and cons for the two proposals? * Are there additional proposals which can address the shortcomings in either? Thanks for your input. [0] Please try to refrain from responses on the line of ha! efficiency! that's hilarious! and ZOMG, polling, that's so last century. Everybody knows this already and it's not germane to the immediate concerns. We'll get to a fully message driven architecture next week. This week we're still working with what we've got. [1] filtering guideline proposal https://review.openstack.org/#/c/177468/ [2] sorting guideline proposal https://review.openstack.org/#/c/145579/ I think that is a reasonable summation. My personal feeling is that if 'changes-since' is strictly defined as the AND of 2 other standard filters, it's not feeling very relevant to recommend it existing. It's now just a 2nd way to do exactly the same thing, and all we can do is screw it up (A man with one watch always knows what time it is. A man with two watches is never quite sure.). If it's left a little more vague of for resources that you expect to be regularly polled, this can provide an interface to only show the consumer relevent resources. If you choose to implement this, you must document what criteria is used to return resources from the url. And allow the possibility that their might be different sensible definitions depending on the resource, I'm happier about it. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [api] [all] To changes-since or not to changes-since
There's an open question in the API-WG on whether to formalize or otherwise enshrine the concept of a changes-since query parameter on collection oriented resources across the projects. The original source of this concept is from Nova's API: http://docs.openstack.org/developer/nova/v2/polling_changes-since_parameter.html There are arguments for and against but we've been unable to reach a consensus so the agreed next step was to bring the issue to the mailing list so more people can hash it out and provide their input. The hope is that concerns or constraints that those in the group are not aware of will be revealed and a better decision will be reached. The basic idea of changes-since is that it can be used as a way to signal that the requestor is doing some polling and would like to ask Give me stuff that has changed since the last time I checked. As I understand it, for the current implementations (in Nova and Glance) this means including stuff that has been deleted. Repeated requests to the resource with a changes-since parameter gives a running report on the evolving state of the resource. This is intended to allow efficient polling[0]. The pro camp on this likes it because this is very useful and quite humane: The requestor doesn't need to know the details of how the query is is implemented under the hood. That is, if there are several timestamps associated with the singular resources in the collection which of those are used for time comparison and which attributes (such as state with a value of deleted) are used to determine if a singular resource is included. The service gets to decide these things and in order for efficient polling to actually be achieved it needs to do in order to make effective queries of the data store. The con camp doesn't like it because it introduces magic, ambiguity and inconsistency into the API (when viewed from a cross-project perspective) and one of the defining goals of the working group is to slowly guide things to some measure of consistency. The alternate approach is to formulate a fairly rigorous query system for both filtering[1] and sorting[2] and use that to specify explicit queries that state I want resources that are newer than time X in timestamp attribute 'updated_at' _and_ have attribute 'state' that is one of 'foo', 'bar' or 'baz'. (I hope I have represented the two camps properly here and not introduced any bias. Myself I'm completely on the fence. If you think I've misrepresented the state of things please post a clarifying response.) The questions come down to: * Are there additional relevant pros and cons for the two proposals? * Are there additional proposals which can address the shortcomings in either? Thanks for your input. [0] Please try to refrain from responses on the line of ha! efficiency! that's hilarious! and ZOMG, polling, that's so last century. Everybody knows this already and it's not germane to the immediate concerns. We'll get to a fully message driven architecture next week. This week we're still working with what we've got. [1] filtering guideline proposal https://review.openstack.org/#/c/177468/ [2] sorting guideline proposal https://review.openstack.org/#/c/145579/ -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] [all] To changes-since or not to changes-since
On Fri, 2015-06-19 at 10:07 +0100, Chris Dent wrote: * Are there additional relevant pros and cons for the two proposals? * Are there additional proposals which can address the shortcomings in either? On the latter question, would using the If-Modified-Since header[1] make any sense as a possible solution? That at least would be a standard HTTP convention for this sort of thing, and tends to match up with the semantics of a changes-since query parameter. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.25 -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] [all] To changes-since or not to changes-since
On 6/19/15, 14:26, Kevin L. Mitchell kevin.mitch...@rackspace.com wrote: On Fri, 2015-06-19 at 10:07 +0100, Chris Dent wrote: * Are there additional relevant pros and cons for the two proposals? * Are there additional proposals which can address the shortcomings in either? On the latter question, would using the If-Modified-Since header[1] make any sense as a possible solution? That at least would be a standard HTTP convention for this sort of thing, and tends to match up with the semantics of a changes-since query parameter. First, please use the updated RFC references (https://tools.ietf.org/html/rfc7232#section-3.3) If-Modified-Since does not. That's meant for entire resources. In other words, let's say you're listing images in Glance and you do GET /v2/images And your response has HTTP/1.1 200 OK Last-Modified: some_last_modified_value In the headers, when you do GET /v2/images If-Modified-Since: some_last_modified_value Then you should either get a: HTTP/1.1 204 No Content Or HTTP/1.1 200 OK Last-Modified: new_last_modified_value (all of the images you saw before) In other words, If-Modified-Since is meant purely for the state of the resource. It's main purpose is when used in conjunction with caching. That said, changes-since is more of a delta. If you need an analogy, think of it as an equivalent to $ git log 2015.1.0..stable/kilo It's just the deltas after a certain timestamp. Cheers, Ian __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
