[PATCH RFC] events-api: allow filtering by date

[aconole]

Ugh. I cannot figure out how to properly respond with this stupid phone. Apologies for the wretched format. 
-------- Original message --------From: Stephen Finucane <stephen at that.guru> Date: 6/21/17  4:47 PM  (GMT-05:00) To: Aaron Conole <aconole at bytheb.org> Cc: patchwork at lists.ozlabs.org Subject: Re: [PATCH RFC] events-api: allow filtering by date 
On Wed, 2017-06-21 at 21:08 +0100, Stephen Finucane wrote:
> On Thu, 2017-06-15 at 09:57 -0400, Aaron Conole wrote:
> > Stephen Finucane <stephen at that.guru> writes:
> > 
> > > On Wed, 2017-06-14 at 14:16 -0400, Aaron Conole wrote:
> > > > Aaron Conole <aconole at bytheb.org> writes:
> > > > 
> > > > > This commit allows users of the REST API to query for events based on
> > > > > the date field.  This will allow utility writers to select a smaller
> > > > > subset of events when polling.
> > > > > 
> > > > > Signed-off-by: Aaron Conole <aconole at bytheb.org>
> > > 
> > > I think I missed this initially because I'd intended to use cursor-based
> > > pagination [1] for '/events'. Cursor-based pagination would be beneficial
> > > in so
> > > far as it allows us to grab a pseudo-permalink to page of events, which
> > > isn't
> > > possible with page number-based pagination because the page numbers can
> > > change
> > > way to darn quick. However, it does make '/events' unique in how it does
> > > pagination. I can go either way with this, and can submit an RFC for this
> > > this
> > > evening, if it would help to compare the two.
> > 
> > Sure; I'm fairly inexperienced with web development, so I don't
> > understand the nuance between the two approaches.
> 
> Sorry for the delay. I've just submitted that RFC now.
> 
> To compare the two, I'd suggest you take a look at the below:
> 
>   https://www.sitepoint.com/paginating-real-time-data-cursor-based-pagination
> /
> 
> The gist is that the high volume of events makes it likely that stuff will
> get
> lost between pages. This really makes sense for '/events' and it might even
> make sense for '/patches' and '/series' (as they're also sorted in
> chronological order by default), though I doubt we'll change those now.

...then again, we could accomplish the same thing with the 'until' filter. So
long as someone specifies this, we shouldn't see anything getting entered in
between the pages.

I think we can ignore my RFC and merge this, if you agree?


Stephen


-------------
Sounds good to me. Sorry for the late reply. I am on vacation and have limited email access. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/patchwork/attachments/20170622/1001af14/attachment.html>