Am 28.02.2018 um 20:14 hat John Snow geschrieben: > > > On 02/28/2018 01:15 PM, Kevin Wolf wrote: > > Is it because you want to avoid that the user picks an automatic job for > > completing the mixed transaction? > > I wanted to avoid the case that a job without the manual property would > be stuck "pending" -- which I have defined to mean that it is waiting on > an authorization from the user -- which isn't really true: it's waiting > on its peers in the transaction to receive that authorization. > > It would indeed be simpler to just let them stick around in PENDING like > their peers, but it felt like a hacky way to allow mixed-mode > transactions -- like they had been promoted for just a subset of their > lifetime. > > So, mostly it was a semantic decision and not a functional one based on > what I considered "WAITING" to mean vs "PENDING". > > If the definitions (and documentation) are adjusted it can be changed > for the simpler layout if it seems just as good from the API > perspective. (It's certainly better implementationally, as you say.)
I actually like it better conceptually, too, because I think of WAITING as a state that waits for jobs in earlier states (i.e. RUNNING/READY usually) and then everything moves forward together. Also waiting for jobs that are already in a later state like PENDING, but only for automatic jobs, makes the mental model more complex (or maybe it's just me...). Kevin
