On Thu, 2017-06-15 at 09:57 -0400, Aaron Conole wrote: > Stephen Finucane <step...@that.guru> writes: > > > On Wed, 2017-06-14 at 14:16 -0400, Aaron Conole wrote: > > > Aaron Conole <acon...@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 <acon...@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 _______________________________________________ Patchwork mailing list Patchwork@lists.ozlabs.org https://lists.ozlabs.org/listinfo/patchwork