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
