launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 29 November 2011 11:48, Robert Collins <robert.collins@xxxxxxxxxxxxx> wrote:
> On Tue, Nov 29, 2011 at 12:51 PM, Martin Pool <mbp@xxxxxxxxxxxxx> wrote:
>
>> Inspired by the notification description here is how I think this
>> could work as a microservice:
>>
>> There is a button ("thanks" or thumbs up) on various objects for which
>> someone might express appreciation: ppas, products, bugs, bug
>> comments, mp comments, etc.
>>
>> There is a table in a separate service of (person_name, person_url,
>> thanked_url).
>
> I think what you want is (object id, object id) - with SOA object
> references (which are still subject to refinement) - otherwise you'll
> be in the business of updating thanks rows on every user rename, which
> isn't a terribly interesting thing to do.

Yes, that's ugly, and I'd overlooked it.

I guess those could still be considered URLs or URIs (resource
identifiers), but the point is they should be genuinely stable and not
necessarily URLs that can be reached externally or in a web browser.
Having them look a bit more like a URI (eg being scoped to a domain
name) rather than just merely an int possibly helps if this is ever
reused by something outside lp.

>
> I also have some suggested tweaks to the API:
>
>> There is a microservice that provides these operations:
>>
>>  give_thanks(person_name, person_url, url) - add a row
>
> -> give_thanks(object id[person], object id[thanked thing])

I wondered if it was useful to cache the realname (even if it goes out
of date) so we don't need N id-name lookups each time.  But perhaps
the lp webapp layer can do that.

>>  get_thanks(person, url) - called by this person (or null), return
>>    - whether the current user thanked that object
>>    - how many people thanked it in total
>>    - a possibly truncated list of some people who thanked it
>
> This should be set based - eg.
> get_thanks (object id[current user], object ids[multiple things to check]):
>  returns a list of (object id checked, did-current-user-thank,
> total-thanks, [object ids of some thankers])
>
>> There are thin api shims in the webapp that pass external requests
>> through to the service after
>   - mapping the current user to a obj id
>   - checking the current user has access to the relevant urls
>
> And so forth - rather than querying each comment, query them all.
> Rather than querying each bug in a bug listing, query them all.

Sure.

-- 
Martin