Re: what to do when calculating totalResults may not scale?

19 views
Skip to first unread message

Ryan B

unread,
Feb 24, 2012, 7:57:07 PM2/24/12
to jsm...@stanfordalumni.org, DeWitt Clinton, portablecontacts, opens...@googlegroups.com
On Fri, Feb 24, 2012 at 4:25 PM, Joseph Smarr <jsm...@gmail.com> wrote:
> I would just not list totalResults if it's hard to get, but are you sure
> there's no easy way to get friend count from FB's APIs? That surprises me...

yeah, Séverin Marcombes said the same thing. you can get it from FQL,
but i chose not to add all the FQL client side code just for
totalResults since a) graph api is better suited for this application
and b) FQL isn't deprecated - they've said so explicitly - but it's
also clearly not their future direction, so i'm reluctant to write
much new code that uses it.

> During the PoCo development process, MSFT also brought up that computing
> totalResults is sometimes expensive, but the consensus was it's usually not
> *that* hard/expensive to calculate and it's really useful info to the
> clients, so we left it in and said "providers: deal with it". :)

fair enough, makes sense. i'll omit it for now but keep it in mind for
later. thanks!

--
http://snarfed.org/

Ryan B

unread,
Feb 24, 2012, 6:36:38 PM2/24/12
to Joseph Smarr, DeWitt Clinton, portablecontacts, opens...@googlegroups.com
hey joseph, dewitt, et al! i know the poco and opensearch specs are
pretty stable right now, but are you accepting feedback for future
revisions?

specifically, i have a case (ahem, facebook) where calculating
totalResults would be inefficient, so i'd like to elide it by
returning an explicit null. unfortunately, the specs expect that you
always return the correct number:

http://portablecontacts.net/draft-spec.html#response-format
http://www.opensearch.org/Specifications/OpenSearch/1.1/Draft_3#The_.22totalResults.22_element

facebook doesn't expose a user's total friend count in the graph api,
so the only way to get it is to fetch all friends and count. they have
paging support and a cap on results returned per call, so calculating
totalResults could technically take O(# friends) serial requests. :/
true, the constant factor is a small fraction, but still.

https://developers.facebook.com/docs/reference/api/user/#friends
https://developers.facebook.com/blog/post/478/

--
http://snarfed.org/

Ryan B

unread,
Mar 2, 2012, 11:12:23 AM3/2/12
to tho...@koch.ro, portable...@googlegroups.com, opens...@googlegroups.com
On Fri, Mar 2, 2012 at 6:13 AM, Thomas Koch <tho...@koch.ro> wrote:
> Ryan B:
>> https://developers.facebook.com/docs/reference/api/user/#friends
>
> the above URI redirects me to the login page, but I don't want to be
> assimilated. Is this a bug or part of the borg protocol? :-)

uh. sorry, yes, it looks like they require you to log in to read the docs.

--
http://snarfed.org/

DeWitt Clinton

unread,
Mar 8, 2012, 11:41:29 AM3/8/12
to Ryan B, jsm...@stanfordalumni.org, portablecontacts, opens...@googlegroups.com
Just noticed this thread.  (I'm also debugging why my mails may not be reaching the list of late, bear with me.)

In the past someone (perhaps even me) proposed an attribute on totalResults for 'estimated=true'.  I can certainly add that back into the latest draft.

That way people could put something like <totalResults estimated="true">10000</totalResults> and do an order of magnitude approximation.  Which, to be honest, is probably a better user experience anyway.

-DeWitt
Reply all
Reply to author
Forward
0 new messages