buy-something team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

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.)

>
> 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?

>
> 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).

-Michael