launchpad-dev team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Monday 27 September 2010 14:51:32 Aaron Bentley wrote:
> On 09/27/2010 07:26 AM, Julian Edwards wrote:
> > On Friday 24 September 2010 22:45:09 Martin Pool wrote:
> >> If we want to take that direction perhaps it's better not considering
> >> it only as a task dispatch system?
> > 
> > I firmly believe that restricting it to a task dispatching system will
> > limit what we can do, so I agree.
> 
> I generally see limiting scope as a good thing, not a bad thing, so I
> don't agree with your conclusion.

My conclusion is little to do with limiting the scope of building a task 
system.  It is everything to do with building a scalable and fast Launchpad.

> We have a clear need for a task
> management system, and we understand what it should be able to do.  I'm
> not convinced that a distributed event system is something we need, or
> that we understand what we will want it to do.

A distributed event system is orthogonal to your assignment to design a new 
job system.  However, since it is likely that we'll be using a messaging 
system to manage the tasks, I'd be extremely upset if you implemented it so 
that its features can't be used outside of the new job system.

I have already explained that I want to use message passing in some of my 
pipelined processing and I don't want to use the Job API to do this, partly 
because it has been an utter disaster trying to bend the API for the build 
farm to use it, and partly because modelling everything as a job is not useful 
when all we want is a simple event.

J