buy-something team mailing list archive

[Michael Nelson <michael.nelson@xxxxxxxxxxxxx>]

On Wed, Jun 23, 2010 at 4:52 PM, Francis J. Lacoste
<francis.lacoste@xxxxxxxxxxxxx> wrote:
> Hi Michael,
>
> Here are my tentative answers to some of you unresolved questions. I didn't
> update the wiki directly, because I wan to be sure that you feel the question
> is resolved :-)

Thanks... I've updated it where appropriate.

>
>  * Given the traffic directed to this request (ie. all clients, not just when
> purchasing), should this be a simple public url resource, rather than a
> lazr.restful api? I'm just thinking in terms of the overhead for anonymous
> access to the LP api - but perhaps that's LP specific. It's not difficult to
> implement simple restful apis with Django (without lazr.restful).
>
> I don't think that's a reason not to use lazr.restful. Anonymous requests to
> the API can and should be cacheable using a front-end proxy. That will ensure
> scalability.

Yep, but what I meant is that it sometime takes a long time for
login_anonymously to return... as I said, maybe that's launchpadlib
specific and we can use true anon access. I've not looked yet at why
lp does this, so it could be a red herring.

>
> I agree with you that lazr.restful adds an extra layer of complexity. I'll let
> Stuart makes the final call on that part, since they will be maintaining the
> agent forward and it's really a question related to ISD technology stack.
>

Sounds good.

> But if you ask me, I think we should use lazr.restful because: a) it's part of
> the standard stack of ISD applications (SSO, Payments and CommPrefs API are
> built using it), b) although doing a simple Restful API is easy, down the road
> when the API becomes more complex, the functionalities of lazr.restful becomes
> more compelling (multi-version support for example).
>
>  * If the agent has to parse the metadata anyway (to verify the price as part
> of "3. I want to buy X" below), is it worth considering storing this part of
> the metadata in the agent itself instead (as Francis suggested) and returning
> the actual information... hence Option 2.
>
> I think you resolved this by understanding that you don't have to verify the
> price: you'll store the price in the agent and use that to make the call to
> the Payments system.

Right, I've removed Option 1 now (where the price/name etc. was
published to the archive... I think mvo said we'll still use the
published metadata for the icons/screenshots though for the moment)

>
>  * What happens if users change their username? Is that possible?
>
> It doesn't matter. The user is identified via the OpenID identifier and that
> doesn't change for a given user. (Not sure how much of this is yet technically
> feasible with SSO) If they change their username, primary email address or
> anything else, the identifier is immutable.

Great. From what I understood from mvo, the client will pass it's
current token, which we'll verify with the SSO api to get the
identifier (and username?).

I had a related question which I forgot in the doc. Why do we want to
add custom code in the Launchpad subscription creation  methods to
accept OpenID identities and create LP users where necessary? Wouldn't
it be better for the agent to get-or-create the lp user using the lp
api (if such a method exists) and then just call the subscription
creation methods with the actual user?

>
>  * How will we cope with ppa-subscription-tokens (and hence apt-get urls)
> being reset in the LP UI. Need some way to refresh the agents information for
> a particular user/ppa when necessary.
>
> Should we let that happen? If somebody has paid for an app, under what
> circumstances should we allow the PPA owner to remove the subscriptions?

The user can reset their subscription token themselves. This was
included in case people thought their p3a subscription had been
compromised (eg., I send it out on an email list by mistake). They can
visit their subscriptions page and reset it and get the new apt-get
lines.

>
> To ensure consistency, we could validate the agent's data before returning to
> the client (making sure that all subscribtions recorded in the Agent are
> really taken into account in Launchpad). The question remains though, who
> should be authoritative for this? Launchpad or the Agent?

For the subscription-token? I think definitely Launchpad since it is
also publishing the .htaccess that enables access for the tokens.

Thanks Francis.

>
>
>
>
> --
> Francis J. Lacoste
> francis.lacoste@xxxxxxxxxxxxx
>
> On June 23, 2010, Michael Nelson wrote:
>> Hi all,
>>
>> Just as an update, I spent the first part of yesterday setting up an
>> ISD django project and looking at the custom tools that they use, and
>> implementing a very rudimentary stub for the "What software is for
>> sale" story (which needs to be changed, but helped me familiarise with
>> schemaconfig and a few other bits and pieces that ISD use).
>>
>> I then got a bit frustrated going over the different views in the
>> email and so created a wiki page which we can use to summarise the
>> current plan:
>>
>> https://wiki.canonical.com/Ubuntu/SoftwareCenter/10.10/Roadmap/SoftwareCent
>> erAgent
>>
>> Please read through it, if you have answers to any of the unresolved
>> questions, please add them. If you have questions, feel free to ask
>> them here on the list for discussion, or add them to the wiki - I'll
>> keep the wiki up to date so we can always see why certain decisions
>> were made without trawling through email.
>>
>> I've been through the doc with mvo which was very helpful, and stuartm
>> has already answered a question too, thanks!
>>
>> I plan to start implementing the stub for "What software is for sale"
>> this afternoon. After that, I'll try to make it really easy to install
>> a dev server of the agent locally, so mvo can start testing. This will
>> give a bit of time for discussion around the other two pieces of
>> initial functionality before we set the API section for those also
>> (hopefully tomorrow), at which point I will implement the stubs for
>> those also.
>>
>> One general question that I have is: do we need to use
>> restfulclient/lazr.restful? I don't mind doing so, but it's not
>> difficult to design a restful app with django without lazr.js (just
>> careful url design with appropriate methods), and lazr.restful is an
>> extra layer of complexity that I'm not sure is worthwhile atm (and
>> it'd suck to have issues like multiple seconds to do anonymous
>> authentication, as we have sometimes on LP).
>>
>> Cheers,
>> -Michael
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~buy-something
>> Post to     : buy-something@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~buy-something
>> More help   : https://help.launchpad.net/ListHelp
>