[Ovirt-devel] Re: Thoughts about taskomatic redesign

[Ian Main]

On Fri, 27 Jun 2008 15:16:49 -0400
Scott Seago <sseago at redhat.com> wrote:

[snip]

> True. There are two steps needed here. "insert this task" and "figure 
> out what it depends on". There are various ways to model this:
> 1) queueing API figures out current deps based on what's in the queue 
> before (or perhaps just after) insertion
> 2) queuing API just inserts the task and whatever API looks for new 
> tasks does the dependency checking.
> 
> It actually probably makes more sense for 1) to happen. Although this 
> API could just be built into the Task ActiveRecord model -- then the WUI 
> would just call Task.insert rather than Task.new.
> 
> > That API would probably also be the right one to expose publically.
> >
> >   
> Right.  Perhaps this public API would be a layer between the current 
> ruby model and controller classes? (then exposed via REST or whatever) 
> -- or would the APIs be built into the model classes themselves (again 
> exposed in the same way)?

This is the big question right now I think.  Not that we need to answer
it right away.  Whatever we use I think the ordering logic should be
in one place, and we need to be able to expose it to multiple language
bindings.

My current thinking is that it should either be a single process that
everyone talks to via the queue API to get things added (so it can do
all the ordering and queuing managing in a serial manner), or that we just
put all that logic into the task implementer threads (taskomatic proper -
just like you said above really :))

   Ian