You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Cassie Doll (JIRA)" <ji...@apache.org> on 2008/06/02 21:59:45 UTC
[jira] Commented: (SHINDIG-318) DataAdapter entries not implemented
[ https://issues.apache.org/jira/browse/SHINDIG-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12601747#action_12601747 ]
Cassie Doll commented on SHINDIG-318:
-------------------------------------
Dave - I don't think this is right. The spec says that:
# A user-defined local group name to select appdata from people in the group (a collection)
# @self to select the appdata for user guid only (a collection)
# @friends to select the appdata from friends of guid only (a collection)
so all of the data returned is always a collection. From json's perspective, fetching app data for one person for one app you could get something like this:
{ entry : { john.doe : {count: 5, favoriteColor : 7} }}
For the opensocial js stuff, this is also very easy to deal with :)
> DataAdapter entries not implemented
> -----------------------------------
>
> Key: SHINDIG-318
> URL: https://issues.apache.org/jira/browse/SHINDIG-318
> Project: Shindig
> Issue Type: Bug
> Components: RESTful API (Java)
> Reporter: David Primmer
>
> APPDATA_OF_APP_OF_USER "/appdata/{uid}/@self/{aid}" needs to be implemented as an TargetType.TYPE_ENTRY and it should return a single Entry and not a list/collection/feed. Currently it's processed as a collection and sent to getEntries with APPDATA_OF_FRIENDS_OF_USER, so it's generated as a feed document.
> There are a few nitpicky issues with it as well. Shouldn't the data interface support just getting a single person's appdata and not return a list similar to the people and activity services?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.