launchpad-dev team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

On Mar 30, 2010, at 9:50 AM, James Westby wrote:

> On Tue, 30 Mar 2010 10:32:01 +0100, Jonathan Lange <jml@xxxxxxxxxxxxx> wrote:
>> And, since my IRC backlog indicates I didn't make it clear enough
>> here, I'm not saying "Go forth and implement this solution", I'm
>> discussing possible solutions to an interesting problem. It would be
>> wise to seek Gary or Leonard's advice on this topic.
> 
> Yes, I'm keen to, as I'm blocked on this, and pretty soon I will have to
> timeout and drop my LP hacking activities for some time to progress
> other things.

I don't want to focus on the question of adapters in launchpadlib right now.  It is an interesting topic, and worth contemplating, but I don't want Leonard or myself to spend the cycles on determining if, and possibly how, the idea might work right now.  That's a conversation topic for a month or three down the road, in my book.

I also really do not want to block James.

Therefore, to get back to this email:

On Mar 29, 2010, at 8:48 AM, Jonathan Lange wrote:

> On Sun, Mar 28, 2010 at 9:58 PM, James Westby <jw+debian@xxxxxxxxxxxxxxx> wrote:
>> On Mon, 29 Mar 2010 08:05:30 +1300, Michael Hudson <michael.hudson@xxxxxxxxxxxxx> wrote:
>> 

...

>>>> Is there some way that I can tell lazr.restful to consider IBranchTarget
>>>> when looking at what to export on IProduct etc?
>>> 
>>> I *think* but without checking the code or really knowing for sure that
>>> you have to make IProduct inherit from IBranchTarget to do this.  But
>>> IIRC products are not IBranchTargets, they are adaptable to
>>> IBranchTargets, and I don't think adaptation is (or really could be) a
>>> concept that translates into the API.
>> 
>> Right, so it sounds like I still need a small interface and mixin to do
>> the adaptation and call newCodeImport on the result?
>> 
> 
> This is the right solution given our current constraints, but it's kind of ugly.

Right.

I hope that this kind of solution does not have much time to propagate before we address the general issue, but meanwhile, lets look the other way on this one.  If the problem rises again, soon, maybe we'll want to push back, but, for now, I'll be optimistic that it won't.

> I know there's a bunch of stuff to do with the webservice API first,
> but do we have any idea how we can have methods on interfaces where
> they make sense and still expose them over the webservice API?

Some ideas, but no consensus yet.  Hopefully we'll be having this conversation soon.

Gary