[Buildbot-devel] New, more efficient web stuff

Dustin J. Mitchell dustin at zmanda.com
Thu Jan 24 17:15:29 UTC 2008


On Jan 6, 2008 4:38 PM, Brian Warner <warner-buildbot at lothar.com> wrote:
> > * status is just the current state -- what's in the configuration, and
> > what's going on right now.  It also generates events for subscribers.
> > * storage keeps the historical record, in a fairly straightforward
> > object-persistence architecture with pluggable backends.
>
> Yay! The buildbot design has IStatus and IBuilderStatus and friends be the
> boundary between build status (past, present, and future) and anyone who is
> interested in it. I'm interested in keeping this interface intact.. I
> couldn't tell if you were suggesting that storage (past build status) be
> reached through a different interface than current build status, but if so,
> I'd prefer to see if we could improve the I*Status interfaces to let it be
> used for both purposes.

This took some thinking, but here's the problem: the persistent stuff
makes *much* heavier use of deferreds, to processing to continue
without waiting for database access.  Status, on the other hand, if it
deals only with "recent" stuff, can just return values immediately
(since they're in RAM).  So the two interfaces are distinct and not
compatible.

I definitely understand the desire to keep I*Status around, but it's
sort of stuck in the middle without a purpose, once the persistent
stuff is added.  So here's my proposal:
 - make all of the process objects provide the corresponding I*Status
interface.  This eliminates a lot of superfluous foo.status or
foo.getStatus() stuff, without significantly adding complexity.  Yes,
you lose the pickle-ability of the status objects -- but that's now
the responsibility of the persistent objects!  Each process object
then contains a pointer to its corresponding persistent object, which
it updates when new data is available.

A little bit of Adapter magic would make it easy to get the
IPersistent* corresponding to an I*Status object, and vice versa,
where one exists.

Dustin

-- 
Storage Software Engineer
http://www.zmanda.com




More information about the devel mailing list