Passing in the computed ids and the idSpec would allow the implementer to do what they wanted. This also solves the problem of the TOP_FRIENDS sort -- currently there's no way to determine this since we don't know if it's the top friends for the owner/viewer given OWNER_FRIENDS or VIEWER_FRIENDS.
On 4/6/08 8:29 AM, "Cassie" <[EMAIL PROTECTED]> wrote: > The js api supports paging, sorting and filtering. See this page: > http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.DataReque > st.PeopleRequestFields.html > > The java api supports pagination for the PeopleService for this function: > > public ResponseItem<ApiCollection<Person>> getPeople(List<String> ids, > SortOrder sortOrder, FilterType filter, int first, int max, > Set<String> profileDetails, GadgetToken token); > > It just doesn't support pagination for the getIds function. We could > add pagination to the getIds function but then that function would > need to know how to sort. But if it needs to know how to sort then it > has to have activity, profile and data info. That doesn't seem like a > really good pattern though. > > One possible way to do things would be to get rid of the getIds > function and to have each getPeople, getActivities, getData call > translate the idSpec into a list of ids itself. That eliminates some > of the nice separation that we currently have though. > > So, I'm not sure how we want to handle this. Feel free to propose a solution. > Thanks. > > - Cassie > > > On Sat, Apr 5, 2008 at 5:41 AM, Raymond Auge <[EMAIL PROTECTED]> wrote: >> >> There should be some way if providing an integer total from the backend to >> the front end... returning a list of 10,000,000 ids is simply not >> acceptable... >> >> Now, I'm fairly certain that no one will ever have 10,000,000 friends... (I >> certainly don't :) ). BUT... it's more an issue of scalability... It is >> certainly conceivable that I have thousands of events... and it'd be nice to >> be able to get that number without ever having to get them all... >> >> These services need methods to return the total for a given userId. >> >> org.apache.shindig.social.opensocial.ActivitiesService >> org.apache.shindig.social.opensocial.PeopleService >> >> This method needs paging support... >> >> List<String> >> org.apache.shindig.social.opensocial.PeopleService.getIds(IdSpec idSpec, >> GadgetToken token) throws JSONException >> >> This method needs paging support: >> >> ResponseItem<List<Activity>> >> org.apache.shindig.social.opensocial.ActivitiesService.getActivities(List<Str >> ing> >> userIds, GadgetToken token) >> >> I think this missing functionality extends all the way to the front end JS >> API. >> >> AGAIN... maybe I'm just not understanding it all correctly. If so, can >> someone explain it to me? >> >> Ray >> >> >> >> On Fri, 2008-04-04 at 23:22 -0400, Raymond Auge wrote: >> Suppose for example I have 10,000,000 Friends... I certainly don't want >> to ever present them all in the UI... secondly, thought I can specify >> that I want one page from "first" to "first + max", but that does not >> provide me with any way to tell the UI that there are 10,000,000, so >> that I can display the total and/or produce a page list... >> >> So, like I said, I might just be missing something and/or not >> understanding the usage of the API (at least from the backend >> perspective)??? >> >> It's simply wrong to have to produce the total based on returning the >> total result set and then pruning out the desired page. >> >> i.e. How can I get the total number of "friends" WITHOUT returning them >> all from the DB? This doesn't seem possible through any of the methods >> in the backend service tier. >> >> >> Ray >> >> On Fri, 2008-04-04 at 10:13 +0200, Cassie wrote: >> >>> Which entities are you talking about? >>> >>> - Cassie >>> >>> >>> On Fri, Apr 4, 2008 at 2:05 AM, Raymond Auge <[EMAIL PROTECTED]> wrote: >>>> Hello All, >>>> >>>> There does not appear to be a way to return the total number of some >>>> entity through any of the APIs. >>>> >>>> I only see a way of returning a list of entities. Not the total count >>>> (which I'd need in order to build some pagination). >>>> >>>> Perhaps I missed something? >>>> >>>> Raymond Augé >>>> Software Engineer >>>> Liferay, Inc. >>>> Enterprise. Open Source. For Life. >>>> >>> >> >> Raymond Augé >> Software Engineer >> Liferay, Inc. >> Enterprise. Open Source. For Life. >> >> >> Raymond Augé >> Software Engineer >> Liferay, Inc. >> Enterprise. Open Source. For Life.
