buy-something team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

On June 17, 2010, Julian Edwards wrote:
> (CC'ing to the new buy-something list, please follow up there.)
> 
> On Thursday 17 June 2010 01:25:36 Francis J. Lacoste wrote:
> > On June 16, 2010, Rick Spencer wrote:
> > > Francis,
> > > 
> > > Thanks for this info and plan. The simplification of federating on the
> > > server side does seem more sound.
> > > 
> > > On Wed, 2010-06-16 at 16:52 -0400, Francis J. Lacoste wrote:
> > > > So next actions from here are:
> > > > 
> > > > * Michael Nelson and Stuart (or somebody else from ISD) should get
> > > > together and kick start a stub project for this.
> > > > 
> > > > * We should stub-out the API to which the client will talk ASAP.
> > > > Ideally, make a local server that responds to the API call with hard
> > > > coded value so that Michael and Gary can do integration testing fast,
> > > > while we work on making this agent work with Soyuz / Payments for
> > > > real on the server side.
> 
> I think we're still missing something here.  We need to define the
> information flow and interactions between parts better, it's still very
> loose and we need it to be very precise so that there are no integration
> surprises (again).
> 
> In terms of the Launchpad side, we want to avoid being hit by all the
> desktops (which is part of the motivation to have this separate "agent"
> component - are we going to call it the Software Center Agent BTW?) so I'd
> like to see the agent periodically polling LP to maintain a list of
> commercial PPAs that contain the apps for sale.  That list can then be
> served statically from the agent or Apache.

Is there still a need to maintain the list of "commercial" PPAs in Launchpad? 
I mean, why not manage that information in the agent itself. List of P3As that 
contain software for sale. 

Why does Launchpad needs that info at all?

> 
> Launchpad itself will provide some webservice calls:
> 
>  * return a list of commercial PPAs, which the agent will call to build its
> list.

Like I'm saying, not sure that is needed.

>  * return a list of existing subscriptions (these are sources.list entries
> in fact)

Even that one is probably not needed. What we need is a way for the agent to 
query if a user is subscribed to a PPA and subscribe him if he's not. From the 
point of view of the Agent, a user is an openid identifier.

The list of stuff you bought is managed in the Agent itself.

>  * allow the agent (and only the agent) to create subscriptions on behalf
> of the commercial PPA's owner

Yes.

>  * return sources.list entry given a person and a PPA

For a given openid identifier and a PPA. The Agent shouldn't care about 
persons. Launchpad needs to handle translation between openid identifiers and 
its association with Person.


> 
> Launchpad is also doing two new custom upload file types on software
> packages: meta-data and icons, which are pushed through to the repository
> area unmodified.  I'm happy for desktops to hit that directly as long as
> IS is okay too, since it's served from Apache, although the agent could
> use the webservice call to get the list of PPAs and then grab the
> meta-data itself - that's up to the people doing the agent.

It all depends if the Agent needs the metadata itself or not. If the flow of 
information is:

1- Sotware Centre asks Agent for list of P3As with stuff.
2- Software Centre retrieves meta data from P3As.

Then I guess the answer is no.

If instead it's:

1- Software Centre asks Agent for meta-data.

Then the answer is yes. And in that case, I'm questioning the need to upload 
the meta-data to Soyuz anyway.

> 
> The last big question that I discussed with Francis last night was how to
> manage the fact that LP currently requires all subscribers to be a Person
> in Launchpad (which was one of the original design aims for it proscribed
> by Mark).  We talked about using OpenID tokens but this is quite a major
> change to the model and is not an area I know much about, so I'd welcome
> further input on how you guys want to manage this.  Francis, you said that
> creating a Person in Launchpad for all the subscribers is okay for now?
> 

Yes, ideally we don't want to pollute the Person table will all of Ubuntu 
customers. Person on Launchpad should be people who contribute to free 
software and uses Launchpad.

But for this initial cut, I think we can live with that limitations. What it 
means:

1- API calls for the Agent, should take openid identifier as user reference.
2- Launchpad needs to translate openid identifier into Person internally and 
when replying
3- If the openid identifier isn't known to us, we need to add it to Account 
and Person. 
4- If we create a Person record for the identifier, we should put a disctinct 
CREATION_RATIONALE so that we can easily retrieve those Person that we can 
delete from the DB later on.

> > > Can the stub be ready by June 30th so that the client side can stay on
> > > schedule?
> > 
> > I'll let Stuart, Michael and Julian decide that. My suggestion would be
> > to define the interface and then export it using lazr.restful.wsgi. The
> > stub could implment all exported methods return fixed value.
> 
> The Launchpad part should be done barring any more undiscovered issues.
> There's a couple of fallback plans in case we do have problems:
>  * Any code we land to change the webservice is available on Edge the next
> day * We have the dogfood server to test with as a last resort if you're
> desperate.
> 
> Finally, the people doing the agent should discuss what interactions with
> other systems they think it needs to do.
> 

For that stub, Launchapd isn't needed at all (except if the meta-data file 
needs to be in Launchpad).

For it to work, we only need to create a P3A with a dud subscription in it. 
And then hard-code all values in the stub to use it. That way the client can 
be "tested" end-to-end.

-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

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