According to the OpenSocial API reference(0.8) the API to fetch people
is newFetchPeopleRequest.

While trying to implement this we have come out with a table listing
all possible combination for the input Idspec and the possible
operations on the result set (sorting and filtering). As per our
understanding and from RESTFul API group Id can be one of the
following :

1.ALL - Collection of all people connected to user irrespective of
network distance.

2.SELF -Profile record for user.

3.FRIENDS - Collection of all friends of user with network distance as
deciding parameter.

4.String representing a name for a collection of contacts as defined
by the user

With this as basis the combinations are listed:

-----------------------------------------------------------
|         IDSpec          |  People Service Params  |
-----------------------------------------------------------
|GroupID | Input        |   Sorting      |    Filtering  |
-----------------------------------------------------------
| All         | userId      |  Name   - Y | HasApp - Y |
|              |                 | TopFr. - ?     | TopFr. - ?    |
-----------------------------------------------------------
| Self      |  userIds[]  |  Name  - Y  | HasApp - Y |
|             |                  | TopFr. - NA  | TopFr. - NA |
-----------------------------------------------------------
| Friends |      userId   |  Name - Y  | TopFr. - Y    |
|             |NetworkDist|  TopFr. - Y | HasApp - Y  |
-----------------------------------------------------------
| group    |    userId    |  Name - Y  | TopFr. - Y  |
| name    |                  |  TopFr. - Y | HasApp - Y |
-----------------------------------------------------------

The main points we wanted to verify were:

On Input:

Only single userId is applicable as input for GroupIDs ALL, FRIENDS
and <group-name> because there is no mechanism to co-relate one user’s
friends from another’s in the response object (Collection<Person>)

NetworkDistance is applicable as input only for GroupID=FRIENDS.

On Top-Friends:

Sorting and Filtering by TopFriends for GroupID=ALL will be dependent
on the logic of Top-Friends in the container since that logic may not
be extendable to non-direct friends.

Sorting and Filtering by TopFriends is Not-Applicable for GroupID=SELF
since the return list will contain disassociated users. (Note: API
Spec says default sort-order is Top-Friends – so what happens in this
case?)

Other:

Pagination is always possible in all conditions (incl. for
GroupID=SELF)

Finally, since IdSpec is also an input for
newFetchPersonAppDataRequest and newFetchActivitiesRequest, the same
restrictions on input apply there as well.

We would like to know if our understanding and assumptions are correct
and whether there are any other possible combinations other than what
have been listed.

TIA
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Implementing OpenSocial Containers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/opensocial-container?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to