just tried with java shindig:
http://www.shindig-demo.org/social/rest/people/@me/@self?st=john.doe%3Ajohn.doe%3A7200%3Ashindig%3Ahttp%253A//www.shindig-demo.org/samplecontainer/examples/SocialHelloWorld.xml%3A0
and it returns the same format:
{"entry":{"id":"john.doe","isViewer":false,"name":{"formatted":"John
Doe","familyName":"Doe","givenName":"John"},"isOwner":false}}
sounds to me that everything is as it should be?
On Fri, Feb 13, 2009 at 1:42 PM, Chris Chabot <[email protected]> wrote:
> I don't know about java, but with php-shindig /social/rest/people/@me/@self
> returns:
>
> {"entry":{"isOwner":true,"isViewer":true,"displayName":"Chris
> Chabot","id":"1","thumbnailUrl":"http:\/\/www.partuza.nl
> \/images\/people\/1.96x96.jpg","profileUrl":"http:\/\/www.partuza.nl
> \/profile\/1"}}
>
> which is exactly as you described it. (steal a security token from an app
> on www.partuza.nl and try it your self on
> http://modules.partuza.nl/social/rest/people/@me/@self?st=<securityToken>)
>
> including totalResults in a single entry seems a bit silly, since this can
> always be hard coded to '1', or have a '404' (not_found) error and no
> entries, hence only wastes bytes and serves to confuse. I guess that could
> be made a bit more clear in the spec text though
>
>
> On Fri, Feb 13, 2009 at 1:35 PM, Ben Smith <[email protected]> wrote:
>
>>
>> On 13 Feb 2009, at 12:25, Chris Chabot wrote:
>>
>> Guys am I on your spam lists and getting redirected to /dev/null or
>>> something? I feel a bit ignored
>>>
>>
>> Sorry.. I'm just a slow typer ;)
>>
>> If you re-read the spec it says:
>>>
>>> " *if the request could possibly return multiple items*" .. then it has
>>> to
>>> be a collection
>>>
>>> /people/@me/@self is a **SINGLE** entry (the viewer, a single entity and
>>> not
>>> a collection of entities) and can **NEVER** return multiple entries, so
>>> that
>>> part in the spec about the collection does not apply.
>>>
>>> The same behavior can be found in activities, a collection is
>>> /activities/@me/@self (since it can return multiple activities), however
>>> /activities/@me/@self/<*ONE ID*> can only return *ONE ENTRY* hence it's
>>> not
>>> a collection.
>>>
>>
>> But then the next section says that /@me/@self requests should still be
>> wrapped by the 'entry' element. The top of 2.1 says that elements like
>> 'totalResults' must be returned too (and doesn't say anything about
>> /@me/@self being different).
>>
>>
>> On Fri, Feb 13, 2009 at 1:18 PM, Ian Boston <[email protected]> wrote:
>>>
>>> Yes that sounds like a good plan :)
>>>>
>>>> Thanks for explaining, I hadn't realized that the current response was
>>>> non
>>>> spec compliant.... so you've fixed a bug as well which is even better.
>>>>
>>>> Thanks,
>>>> Ian
>>>>
>>>>
>>>>
>>>> On 13 Feb 2009, at 11:56, Ben Smith wrote:
>>>>
>>>> I'd personally prefer that as you'd get a more consistent response.
>>>>
>>>>> However, this would change the current response for @self requests as
>>>>> it
>>>>> would be wrapped in the output of a RestfulCollection object. Currently
>>>>> a
>>>>> response for an @self request returns
>>>>> <response><person></person></response>
>>>>> where as a request to @friends returns
>>>>> <response><entry><person></person>[..]</entry></response>.
>>>>>
>>>>> Interestingly.. if you read
>>>>>
>>>>> http://opensocial-resources.googlecode.com/svn/spec/draft/REST-API.xml#rfc.section.3.1
>>>>> it
>>>>> agrees with you, that every request should be assumed to be a
>>>>> collection,
>>>>> even if it will only ever have one entry!
>>>>>
>>>>> entry: an array of objects, one for each item matching the request, as
>>>>> defined in Section 11.1. For consistency of parsing, if the request
>>>>> could
>>>>> possibly return multiple items (as is normally the case), this value
>>>>> MUST
>>>>> always be an array of results, even if there happens to be 0 or 1
>>>>> matching
>>>>> results. If the request is specifically for a single contact (e.g.
>>>>> because
>>>>> the request contains Additional Path Information like /@me/@all/{id} or
>>>>> /@me/@self), then entry MUST be an object containing the single item
>>>>> returned (i.e. "entry": [ { /* first item */ } ] and "entry": { /* only
>>>>> item
>>>>> */ } respectively).
>>>>>
>>>>> Therefore, I'll rescind my current patch and provide one that has
>>>>> PersonHandler only use getPeople(). Plan?
>>>>>
>>>>> Cheers,
>>>>> Ben
>>>>>
>>>>> On 13 Feb 2009, at 11:42, Ian Boston wrote:
>>>>>
>>>>> Ben,
>>>>>
>>>>>>
>>>>>> What is wrong with doing:
>>>>>>
>>>>>> personService.getPeople(personSet, GroupId.Type.all,
>>>>>> collectionOptions,
>>>>>> fieldsSet, securityToken);
>>>>>>
>>>>>> where personSet contains only the currentUser and the
>>>>>> collectionOptions
>>>>>> is as per the URL.
>>>>>>
>>>>>> ?
>>>>>>
>>>>>> If that would give you what you want, there is no SPI change required.
>>>>>> (tell me I have missed something if I have, no coffee yet :)
>>>>>> )
>>>>>> Ian
>>>>>>
>>>>>> On 13 Feb 2009, at 11:32, Ben Smith wrote:
>>>>>>
>>>>>> Please could someone have an opinion about
>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/SHINDIG-904
>>>>>>>
>>>>>>> There's a chance I need to provide a new patch as there have been
>>>>>>> quite
>>>>>>> a few changes since I originally provided it.
>>>>>>>
>>>>>>> It is quite important for me to be able to provide the standard
>>>>>>> parameters for 0.9:
>>>>>>>
>>>>>>> http://opensocial-resources.googlecode.com/svn/spec/draft/REST-API.xml#standardQueryParameters
>>>>>>> and
>>>>>>> these need to be available to getPerson() to support the following
>>>>>>> query:
>>>>>>>
>>>>>>> /people/@me/@self?filter...@friends&filterOp=contains&filterValue=<someUserId>
>>>>>>>
>>>>>>> I realise that this change involves changing an SPI interface but
>>>>>>> this
>>>>>>> is the smallest, simplest change that was discussed a while ago,
>>>>>>> which I
>>>>>>> then submitted this patch for.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Ben Smith
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>
