On Mon, Nov 23, 2009 at 12:38 PM, Michael Nelson < [email protected]> wrote:
> > > On Mon, Nov 23, 2009 at 8:57 AM, Michael Nelson < > [email protected]> wrote: > >> >> >> On Wed, Nov 18, 2009 at 7:15 AM, Michael Hudson < >> [email protected]> 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
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
