launchpad-dev team mailing list archive

[Guilherme Salgado <salgado@xxxxxxxxxxxxx>]

I've done this a try [1] and the changes needed to make lazr.restful do
what we want are not too complicated.  The only thing you won't have
with these changes is the ability to extend a top level collection, but
it should be possible to do something similar for them if we ever need
-- we currently don't seem to need it, and that's why I haven't
bothered.

[1]
https://code.edge.launchpad.net/~salgado/lazr.restful/extension-interfaces/+merge/29388

On Tue, 2010-06-29 at 15:45 -0400, James Westby wrote:
> On Mon, 29 Mar 2010 14:59:12 -0400, Leonard Richardson <leonard.richardson@xxxxxxxxxxxxx> wrote:
> > Assuming I understand what you're trying to do, the simplest way to
> > represent this would be to define an annotation like
> > @import_from_adapter() and put @import_from_adapter(IBranchTarget) in
> > IProduct and ISourcePackage, while leaving it out of IPerson and
> > IProductSeries.
> > 
> > In IBranchTarget you would have an annotation like
> > @only_used_in_adaptations that would stop it from being exported as a
> > separate entry type. You would publish IBranchTarget.name as
> > "branch_target_name" (or whatever you wanted) to avoid colliding with a
> > 'name' declared in IProduct or ISourcePackage. The same would hold true
> > for IBranchTargetName's named operations. You can choose whatever name
> > you want, but if that name conflicts with a name found in the original
> > interface, the original interface takes precedence.
> > 
> > The end result would be 'product' and 'source_package' looking like they
> > had everything that's @exported in IBranchTarget. Behind the scenes, a
> > product or source package would be adapted to IBranchTarget to retrieve
> > values like 'branch_target_name'. A PATCH that modified (eg.) both name
> > and branch_target_name would make both object modifications within a
> > single database transaction.
> 
> This just came up again in a different situation, with a couple of
> additional requirements.
> 
> What we would like to do is avoid registry importing from so many of the
> other apps, to avoid the circular dependencies.
> 
> To do this we are currently looking at having ISomething interfaces in
> the apps (bugs, code, soyuz etc.) that define an interface relevant to
> them. This is standard practice for a lot of things, see IBugTarget,
> IHasBranches etc.
> 
> The implementations of these are then adapters, which isn't usually the
> case.
> 
>   class ProductToBugTarget():
>        adapts(IProduct)
>        implements(IBugTarget)
> 
> This means that all the bugs-specific code can live in lp.bugs.
> 
> This means that we want something similar to before, where some IProduct
> methods should be made available over the webservice by adapting the
> IProduct and calling the methods on the result.
> 
> 
> In order to break the circular dependency we need to stop IProduct from
> deriving from IBugTarget as well. In our experimental branch we  define
> a marker interface in lp.registry for things that can be adapted to bug
> targets, which helps with registration etc.
> 
>   class IProduct(ICanBeBugTarget):
> 
> The wrinkle that this has it that it doesn't accomodate the webservice.
> 
> Currently in order for IBugTarget methods to be available on IProduct
> they have to be available in the interface that IProduct derives from,
> currently IBugTarget, which means that bugs code has to be imported in
> to the registry.
> 
> Using ICanBeBugTarget means that IBugTarget can't add methods to
> IProduct right now. Therefore we want a way to annotate that extra
> methods should be added from the webservice point of view, but
> crucially, we don't want to import the bugs interface in order to do
> that.
> 
>   class ICanBeBugTarget(Interface):
> 
>       @import_from_adapter(IBugTarget)
> 
> requires importing lp.bugs.interfaces.bugtarget.IBugTarget, which gives
> us the circular dependencies again.
> 
> Would it be possible for us to instead have something like:
> 
>   class ProductToBugTarget():
> 
>       @only_used_in_adaptations
>       @add_things_to(IProduct)
> 
> such that the arrow is drawn the other way, and apps can add things to
> registry objects without the registry having to import them?
> 
> I don't see why this can't be done, except that it means that finding
> out the methods on an object is now a global operation, requiring
> importing everything and considering the result, rather than just
> importing the interface and scanning it.
> 
> Thanks,
> 
> James

-- 
Guilherme Salgado <https://launchpad.net/~salgado>

Attachment: signature.asc
Description: This is a digitally signed message part