what to do when calculating totalResults may not scale?

[Ryan B]

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/

[Joseph Smarr]

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... or you could list 5000 (max number) until you page to the end, at which point you return the actual total so the client knows to stop paging. Kind of a hack, but maybe better than confusing the user into thinking you returned all the friends when you didn't?

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

[Ryan B]

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/

[Thomas Koch]

Ryan B:
> https://developers.facebook.com/docs/reference/api/user/#friends

Hi Ryan,

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

Regards,

Thomas Koch, http://www.koch.ro

[Ryan B]

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/