[PATCH RFC] events-api: allow filtering by date
stephen at that.guru
Thu Jun 22 06:08:23 AEST 2017
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  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:
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
> 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
> 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.
More information about the Patchwork