buy-something team mailing list archive

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

On June 17, 2010, Michael Nelson wrote:
> On Thu, Jun 17, 2010 at 12:41 PM, Julian Edwards
> 
> <julian.edwards@xxxxxxxxxxxxx> wrote:
> > (CC'ing to the new buy-something list, please follow up there.)
> 
> Still CC'ing everyone in case people haven't set the subscription in
> their LP account.
> 
> > 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.
> 
> I understand that the aim is that the desktop client doesn't hit
> launchpad, but I'm unclear whether the desktop client will also be
> parsing the meta data/icons directly (based on a list of commercial
> ppas provided by the agent), or whether this data will be parsed by
> the agent and provided to desktop clients.
> 
> Based on your comment above Julian, it sounds like the former
> (actually, you addressed this below), but based on Francis'
> requirement that the agent should answer: "What [apps are] available
> for sale? (for a given distroseries)", I'd assume the agent needs to
> parse these files itself so that the results of available apps can be
> returned with different criteria (distroseries, category, name search,
> eventually pagination etc.)

Like I said in my other reply, it all depends on the client. I know for sure 
that the client will parse those files. It needs to for the "Opening the 
flood-gate" story. (Shipping apps after release in a PPA.)

So I think, the web service call to make is really: Give me the list of P3A 
archive from which I need to download meta-data.

> 
> > Launchpad itself will provide some webservice calls:
> > 
> >  * return a list of commercial PPAs, which the agent will call to build
> > its list.
> >  * return a list of existing subscriptions (these are sources.list
> > entries in fact)
> >  * allow the agent (and only the agent) to create subscriptions on behalf
> > of the commercial PPA's owner
> >  * return sources.list entry given a person and a PPA
> > 
> > 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.
> 
> As above, I assume it'll need to be the agent parsing these files to
> be able to supply the relevant information for desktop requests?

I don't think the Agent needs to parse any file. I think the minimum amount of 
info it requires is:

Name of P3A containing an app, price of access to that P3A.



> 
> > 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?
> > 
> >> > 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.
> 
> Yep, I'll hope to get started next week. Where can I read the API
> documentation for the payment gateway that's being implemented? Also,
> I assume we'll need a private project (or private branches) if the
> code is going to be exposing the API for the payment gateway, or is
> this ok being public (as long as the real config options etc., are not
> stored in the branch of course).
> 

The payment systems has very minimal documentation. There are a few doctests 
in lp:~canonical-isd-hackers/canonical-payment-service/trunk/

Like all ISD projects, we should use a private branch to develop it. You'll 
need guidance from Stuart Metcalf to bootstrap that project.

Cheers
-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

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