launchpad-dev team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

On Mon, Nov 23, 2009 at 12:38 PM, Michael Nelson <
michael.nelson@xxxxxxxxxxxxx> wrote:

>
>
> On Mon, Nov 23, 2009 at 8:57 AM, Michael Nelson <
> michael.nelson@xxxxxxxxxxxxx> wrote:
>
>>
>>
>> On Wed, Nov 18, 2009 at 7:15 AM, Michael Hudson <
>> michael.hudson@xxxxxxxxxxxxx> wrote:
>>
>>
>>> Julian Edwards wrote:
>>> > There is one nightmare part to this - the implementation of
>>> > IBuilder.findBuildCandidate().  This is currently a very ugly query
>>> that
>>> > decides which job to dispatch next, based on a few criteria about the
>>> jobs.  I
>>> > expect it to get to troll-like ugliness by the time we finish and I'm
>>> not sure
>>> > how it will work yet, it depends on how Michael re-factors IBuilder and
>>> sets
>>> > up an interface that other builders must implement.
>>>
>>> Wow, that's a beauty alright.
>>>
>>>
OK, I had a bit of time to look at this today. Just in terms of a
pre-implementation discussion, here's what I'm planning to do tomorrow - so
if you see any flaws or improvements in my plan or assumptions, please let
me know.

The specialized builders need to both (a) augment existing functionality
(eg. startBuild()), and (b) provide some additional different functionality
(eg. checkCanBuildForDistroArchSeries()).

My assumption is that all call-sites will know whether they want a specific
type of builder, or be happy to deal with a set of general builders (ie. a
view listing all builders).

The approach that I'm planning to take tomorrow is to (note bigjools, this
is different to the initial example I showed you earlier):

1) Create IPackageBuilder (or IBinaryPackageBuilder) as an extension of the
IBuilder interface.
2) Create a PackageBuilder (or BinaryPackageBuilder) content-class that uses
composition + delegation to provide the IBuilder general functionality while
adding custom functionality or augmenting existing functionality of IBuilder
(using lazr.delegates).
3) Provide adapters for IBuilder->IPackageBuilder etc., so that call-sites
can grab a builder and adapt it as required.
4) Where appropriate, provide hooks in any general Builder methods that will
need additional behaviour so that customisations will generally (but not
necessarily) follow a standard api.

Also, when a builder is building it will have a know job type and so can
potentially adapt itself (via the job/build queue entry). Not sure if this
will be necessary.

This means that the general IBuilder interface/class won't need to know
about the specializations (or be updated when new specialized builders are
added).

Cheers,
Michael