On June 17, 2010, Michael Nelson wrote: > On Thu, Jun 17, 2010 at 12:41 PM, Julian Edwards > > <[email protected]> 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 [email protected]
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Mailing list: https://launchpad.net/~buy-something Post to : [email protected] Unsubscribe : https://launchpad.net/~buy-something More help : https://help.launchpad.net/ListHelp
