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

[Stephen Finucane]

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.

> > > > ---
> > > 
> > > It should be noted that my motivation for this is to implement a git-pw
> > > event poll command for CI integration.
> > 
> > Hmm, so I'll admit I'm not overly fond of this idea. I'm trying to keep
> > git-pw
> > as a client side tool for git-patchwork interaction and not a catch-all
> > application for all things Patchwork like pwclient currently is. "Create a
> > check" doesn't sound like something Acme developer would be doing from
> > within
> > their Git repo.
> 
> Okay.  I'm approaching this from the angle of "I want to do X, how do I
> achieve it today." :)  I thought it made sense to have a running stream
> of events that I could poll on, especially since I envision the workflow
> like:
> 
> 1. Wake up
> 2. Do human things
> 3. git pw events list --category=series-new* --since=<last time>
> 4. scroll through that work (ie: git pw series apply X, review, comment,
>    etc. keep going until all are done)
> 5. go to 3.

Actually, that makes sense. I'd be game to accept a PR for this. What I
wouldn't be a fan of is integrating checks and I thought this is what you were
suggesting.

> Maybe I'm not thinking about events correctly, though?
> 
> Then I could basically make steps 3,4,5 be done by a machine instead,
> and have it run things like checkpatch, make check, etc.  I'll look at
> the snowpatch tool, as well.  Thanks.

Yeah, anything that can be automated should be. Machines, however, shouldn't be
using git-pw - they should make their own calls or use some kind of as-yet-non-
existent Patchwork REST library.

Cheers,
Stephen