This isnt really my thread, but, as someone who might have to provide
the implementation.
I would support putting the separation below the API, ie getPeople,
getActivities, getData
since if its above the API
A) the implementation of the API is restricted in how it expresses
and selects ID's (eg has to return the whole set, which in the case
of people may be large, activities would probably have some natural
server defined limit (eg last 30 days or 30 items, whichever is less)
B) it reduces the chattiness over the API, improving possibilities to
remote the call in necessary.
C) it frees the implementation from exposing its internal ID's or
translating to another form.
there is nothing really compelling in any of these arguments for
getPeople, getActivities, getData but it just feels like a simpler
API and may prevent a double get on the data under the API.
A concrete example.
I store my recent activity in a lucene index (its fast :) )+indexing
backlog queue, with a date field and I can perform a search on that
index with a custom query string, from which I retrieve the ID's, but
for the list of ID's i need to emit 1 query (or a compound query for
a set) per ID..... when I had a good pointer to the record in the
first call.
I store the Data in Jackrabbit, so when I get the ID's under getData
I do a jcr getNode(), this pulls into memory all the contents of the
node, just to extract some concept of an ID. Later on in the next
call I need to convert the getNode() ID into the real data, hence I
call getNode() again.... fortunately Jackrabbit has excellent
caching, so there is no problem, it just comes from memory.
I think I am saying, in practice, the cost of the getIDs type call
may be as expensive (if not more without filtering and sorting) as
the final get data call... so why not do the get data call in the
first place ?
As I said, not my thread, sorry for butting in.
Ian
On 6 Apr 2008, at 16:29, Cassie wrote:
The js api supports paging, sorting and filtering. See this page:
http://code.google.com/apis/opensocial/docs/0.7/reference/
opensocial.DataRequest.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<String>
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.
