You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Ben Smith <be...@gmail.com> on 2009/02/13 12:32:58 UTC
Extension to getPerson for 0.9
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?
filterBy=@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
Re: Extension to getPerson for 0.9
Posted by Ian Boston <ie...@tfd.co.uk>.
On 13 Feb 2009, at 13:00, Ben Smith wrote:
>> having called getPeople check the response and emit a 404 if there
>> are 0 entries and the only entry if there is 1 (there should not be
>> more than 1 as a result of the filter). Obviously the Future needs
>> to be wrapped to evaluate this when its needed and not before.
>
> Sounds good. I'm assuming you mean *unwrapped*?
yes, converting a Future<RC<Person>> into a Future<Person> without
actually extracting the RC<Person> when the Future<Person> is created.
SPI implementations might use something other than ImmediateFuture.
Re: Extension to getPerson for 0.9
Posted by Chris Chabot <ch...@google.com>.
bah just upgraded that build, and it seems java-shindig's samplecontainer is
properly broken at the moment?
On Fri, Feb 13, 2009 at 2:03 PM, Chris Chabot <ch...@google.com> wrote:
>
>
> On Fri, Feb 13, 2009 at 2:00 PM, Ben Smith <be...@gmail.com> wrote:
>
>> Yeah, this is quick moving.
>>
>> I think Chris is right and there may be a problem with the response format
>> for Java. Does anyone know when shindig-demo.org was last deployed? I'm
>> am getting different results.
>>
>
> That build is about a month and a half old, i had tried to update it in the
> meantime but build errors kept me from doing so
>
>
>
Re: Extension to getPerson for 0.9
Posted by Chris Chabot <ch...@google.com>.
On Fri, Feb 13, 2009 at 2:00 PM, Ben Smith <be...@gmail.com> wrote:
> Yeah, this is quick moving.
>
> I think Chris is right and there may be a problem with the response format
> for Java. Does anyone know when shindig-demo.org was last deployed? I'm am
> getting different results.
>
That build is about a month and a half old, i had tried to update it in the
meantime but build errors kept me from doing so
Re: Extension to getPerson for 0.9
Posted by Ben Smith <be...@gmail.com>.
Yeah, this is quick moving.
I think Chris is right and there may be a problem with the response
format for Java. Does anyone know when shindig-demo.org was last
deployed? I'm am getting different results.
On 13 Feb 2009, at 12:52, Ian Boston wrote:
> Can I unwind this a little please.
>
> The original patch for 904 was to introduce a change the SPI for
> getPerson with filtering.
> I argued that getPeople already provides the filtering so there was
> no need for a SPI change.
> Ben pointed out that the REST response would then be a collection
> which exposed a tension in the spec.
>
> Did I get that right?
>
> Lets assume for a moment that the output of the current servlet *is*
> correct (ie not a collection)
>
> having called getPeople check the response and emit a 404 if there
> are 0 entries and the only entry if there is 1 (there should not be
> more than 1 as a result of the filter). Obviously the Future needs
> to be wrapped to evaluate this when its needed and not before.
Sounds good. I'm assuming you mean *unwrapped*?
> Does that make sense?
>
> I think if they current servlet is not correct then that needs
> sorting out separately, but I see emails on this thread stacking up
> faster than I can type or think or answer the phone.
>
> Ian
>
> On 13 Feb 2009, at 12:36, Chris Chabot wrote:
>
>> On Fri, Feb 13, 2009 at 1:27 PM, Ben Smith <be...@gmail.com>
>> wrote:
>>
>>> On 13 Feb 2009, at 12:09, Chris Chabot wrote:
>>>
>>> '@self' is not a collection by any definition of the word, it's a
>>> single
>>>> object, hence the lack of the collection (and the lack of
>>>> filtering, there
>>>> is only one 'self' and that's the viewer :)
>>>>
>>>> The same goes for activities, a query on /activities/@me/@self
>>>> returns a
>>>> collection of activities (since it can contain 0, 1 or many
>>>> results),
>>>> however /activities/@me/@self/<activityId> can only return 0 or 1
>>>> results,
>>>> so it returns an activity record and not a RestfulCollection.
>>>>
>>>
>>> But that's not what the spec says should happen: 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).
>>>
>>> Unless I'm reading it wrong, /@me/@self should still return
>>> <response><entry><person></person></entry></response>
>>
>>
>>
>> There are 2 parts to the definition:
>>
>> 1) 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 something could return multiple entries it has to be a collection,
>> however /@me/@self is a single entry, so this doesn't apply here
>>
>> 2) 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
>>
>> So if the query is for /@me/@self it *MUST be a single entry.*
>>
>> I think your either confused and consfusing /@me/@self with /@me/
>> @all (which
>> is an PortableContacts way of saying /@me/@friends), or your a
>> believer in
>> possessions and believe that our definition of a person being a
>> singular
>> entity is wrong and the spec should be changed to allow for
>> multiple spirits
>> and/or demons in one physical body. (And i truly hope that is not
>> what your
>> suggesting :)
>>
>>
>>
>>> I agree that filterBy=@friends&filterValue=<userId> is confusing,
>>> but
>>> filterBy=id&filterValue=<userId> would surely remove all people
>>> that do not
>>> have <userId> as their userId! I guess you really want a filterBy
>>> AND
>>> filterOn (or something), or explicitly name filterValue to
>>> filterUserIdValue
>>> (or something).
>>>
>>
>> Filtering on /@me/@self is confusing, since it's only one record,
>> what would
>> you want to filter on?
>
Re: Extension to getPerson for 0.9
Posted by Ben Smith <be...@gmail.com>.
Right. I've got a patch in that should do this: https://issues.apache.org/jira/browse/SHINDIG-918
Let me know if this is good enough.
Ps. The samples project is broken again. Very simple fix: https://issues.apache.org/jira/browse/SHINDIG-917
On 13 Feb 2009, at 13:47, Ian Boston wrote:
> Sounds good,
>
> So thats a call to getPeople(....)
> put the Future response inside another Future response that unwrapps
> the RC<Person> into a Person... if there is one, otherwise respond
> with a 404.
>
> and yes a single entry not a collection.
>
> Ian
> On 13 Feb 2009, at 13:41, Chris Chabot wrote:
>
>> Ah right, yeah that's indeed from
>> http://wiki.opensocial.org/index.php?title=Implementing_IS_FRIENDS_WITH
>>
>> In which case I guess we should respond to that one filter option
>> in the
>> getPerson(), however it should still be a single entry and not a
>> collection
>> :)
>>
>>
>> On Fri, Feb 13, 2009 at 2:30 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>
>>> I agree filtering on a single entity is silly:
>>> But under the table of section 7.9 of the spec at
>>> http://opensocial-resources.googlecode.com/svn/spec/draft/REST-API.xml
>>>
>>> "
>>>
>>>
>>> /people/@me/@self?
>>> filterBy=@friends&filterOp=contains&filterValue=<someUserId>
>>>
>>>
>>> This will return nothing if the other ID is not a friend, the
>>> current user
>>> if the two are friends. filterValue may take a specific person
>>> identifier of
>>> @owner or @viewer.
>>>
>>> "
>>>
>>> Which implies that filtering on the *single* @me/@self entity is
>>> the way to
>>> find if the current user is friends with the specified user.
>>>
>>> Back in the early thread, (about a week ago) I think I said the
>>> spec looked
>>> odd.
>>>
>>> This is where the original URL that started this thread comes from.
>>> ---------------------------
>>>
>>> So a question for you, Chris,
>>> should /people/@me/@self respond to filtering?
>>>
>>>
>>>
>>> Ian
>>>
>>>
>>>
>>>
>>> On 13 Feb 2009, at 12:58, Chris Chabot wrote:
>>>
>>> There's really no need to assume anything, /people/@me/@self is a
>>> single
>>>> entity and can never be more then one result.
>>>>
>>>> Hence filtering is a bit silly, what exactly would you want to
>>>> filter on,
>>>> what would be the use-case for wanting to know a viewer *only if
>>>> <condition>* ?
>>>>
>>>> The only situation in which /people/@me/@self returns an error is
>>>> when
>>>> your
>>>> using 2 legged OAuth (or anonymous read access is allowed), in
>>>> which case
>>>> the securityToken's getViewer() will throw an exception since @me
>>>> can't be
>>>> resolve to an ID in those situations.
>>>>
>>>> In every other situation, getViewer() returns an id, which is
>>>> used to
>>>> resolve @me/@self to a single user record, which is not really
>>>> filterable,
>>>> since filtering only makes sense on collections, right?
>>>>
>>>> On Fri, Feb 13, 2009 at 1:52 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>>>
>>>> Can I unwind this a little please.
>>>>>
>>>>> The original patch for 904 was to introduce a change the SPI for
>>>>> getPerson
>>>>> with filtering.
>>>>> I argued that getPeople already provides the filtering so there
>>>>> was no
>>>>> need
>>>>> for a SPI change.
>>>>> Ben pointed out that the REST response would then be a
>>>>> collection which
>>>>> exposed a tension in the spec.
>>>>>
>>>>> Did I get that right?
>>>>>
>>>>> Lets assume for a moment that the output of the current servlet
>>>>> *is*
>>>>> correct (ie not a collection)
>>>>>
>>>>> having called getPeople check the response and emit a 404 if
>>>>> there are 0
>>>>> entries and the only entry if there is 1 (there should not be
>>>>> more than 1
>>>>> as
>>>>> a result of the filter). Obviously the Future needs to be
>>>>> wrapped to
>>>>> evaluate this when its needed and not before.
>>>>>
>>>>> Does that make sense?
>>>>>
>>>>> I think if they current servlet is not correct then that needs
>>>>> sorting
>>>>> out
>>>>> separately, but I see emails on this thread stacking up faster
>>>>> than I can
>>>>> type or think or answer the phone.
>>>>>
>>>>> Ian
>>>>>
>>>>>
>>>>> On 13 Feb 2009, at 12:36, Chris Chabot wrote:
>>>>>
>>>>> On Fri, Feb 13, 2009 at 1:27 PM, Ben Smith
>>>>> <be...@gmail.com>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> On 13 Feb 2009, at 12:09, Chris Chabot wrote:
>>>>>>
>>>>>>>
>>>>>>> '@self' is not a collection by any definition of the word,
>>>>>>> it's a
>>>>>>> single
>>>>>>>
>>>>>>> object, hence the lack of the collection (and the lack of
>>>>>>> filtering,
>>>>>>>> there
>>>>>>>> is only one 'self' and that's the viewer :)
>>>>>>>>
>>>>>>>> The same goes for activities, a query on /activities/@me/
>>>>>>>> @self returns
>>>>>>>> a
>>>>>>>> collection of activities (since it can contain 0, 1 or many
>>>>>>>> results),
>>>>>>>> however /activities/@me/@self/<activityId> can only return 0
>>>>>>>> or 1
>>>>>>>> results,
>>>>>>>> so it returns an activity record and not a RestfulCollection.
>>>>>>>>
>>>>>>>>
>>>>>>>> But that's not what the spec says should happen: 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).
>>>>>>>
>>>>>>> Unless I'm reading it wrong, /@me/@self should still return
>>>>>>> <response><entry><person></person></entry></response>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> There are 2 parts to the definition:
>>>>>>
>>>>>> 1) 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 something could return multiple entries it has to be a
>>>>>> collection,
>>>>>> however /@me/@self is a single entry, so this doesn't apply here
>>>>>>
>>>>>> 2) 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
>>>>>>
>>>>>> So if the query is for /@me/@self it *MUST be a single entry.*
>>>>>>
>>>>>> I think your either confused and consfusing /@me/@self with /
>>>>>> @me/@all
>>>>>> (which
>>>>>> is an PortableContacts way of saying /@me/@friends), or your a
>>>>>> believer
>>>>>> in
>>>>>> possessions and believe that our definition of a person being a
>>>>>> singular
>>>>>> entity is wrong and the spec should be changed to allow for
>>>>>> multiple
>>>>>> spirits
>>>>>> and/or demons in one physical body. (And i truly hope that is
>>>>>> not what
>>>>>> your
>>>>>> suggesting :)
>>>>>>
>>>>>>
>>>>>>
>>>>>> I agree that filterBy=@friends&filterValue=<userId> is
>>>>>> confusing, but
>>>>>>
>>>>>>> filterBy=id&filterValue=<userId> would surely remove all
>>>>>>> people that do
>>>>>>> not
>>>>>>> have <userId> as their userId! I guess you really want a
>>>>>>> filterBy AND
>>>>>>> filterOn (or something), or explicitly name filterValue to
>>>>>>> filterUserIdValue
>>>>>>> (or something).
>>>>>>>
>>>>>>>
>>>>>>> Filtering on /@me/@self is confusing, since it's only one
>>>>>>> record, what
>>>>>> would
>>>>>> you want to filter on?
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>
Re: Extension to getPerson for 0.9
Posted by Ben Smith <be...@gmail.com>.
Fair enough. XSD says it's cool. This should probably be reflected in
the spec.. but I'm not going to loose any more sleep over it ;)
On 13 Feb 2009, at 14:59, Ian Boston wrote:
> The XML Schema was aligned with portable contacts, and a version of
> that xsd is used to validate the responses.
> So the response you see from the sample container *should* be
> correct wrt the xsd.
>
> Since that work was done, the xsd has moved on a small amount, but I
> think the response is correct, no entry. Inspecting the xsd should
> be validate that. see section 2.2 of http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/restful-protocol
>
> or
>
> http://svn.apache.org/repos/asf/incubator/shindig/trunk/java/social-api/src/test/resources/org/apache/shindig/social/opensocial/util/opensocial.xsd
>
> I think this says <person> can be a top level element.
> Ian
> On 13 Feb 2009, at 14:35, Ben Smith wrote:
>
>> Cool.
>>
>> FYI. Running Jetty from trunk and going to /people/canonical/@self?
>> format=xml gives the following response:
>>
>> <response><person>
>> <id>canonical</id>
>> ...
>> </person></response>
>>
>> I'm guessing that is a bug as there is no <entry> wrapped around
>> the person object?
>>
>> On 13 Feb 2009, at 13:47, Ian Boston wrote:
>>
>>> Sounds good,
>>>
>>> So thats a call to getPeople(....)
>>> put the Future response inside another Future response that
>>> unwrapps the RC<Person> into a Person... if there is one,
>>> otherwise respond with a 404.
>>>
>>> and yes a single entry not a collection.
>>>
>>> Ian
>>> On 13 Feb 2009, at 13:41, Chris Chabot wrote:
>>>
>>>> Ah right, yeah that's indeed from
>>>> http://wiki.opensocial.org/index.php?title=Implementing_IS_FRIENDS_WITH
>>>>
>>>> In which case I guess we should respond to that one filter option
>>>> in the
>>>> getPerson(), however it should still be a single entry and not a
>>>> collection
>>>> :)
>>>>
>>>>
>>>> On Fri, Feb 13, 2009 at 2:30 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>>>
>>>>> I agree filtering on a single entity is silly:
>>>>> But under the table of section 7.9 of the spec at
>>>>> http://opensocial-resources.googlecode.com/svn/spec/draft/REST-API.xml
>>>>>
>>>>> "
>>>>>
>>>>>
>>>>> /people/@me/@self?
>>>>> filterBy=@friends&filterOp=contains&filterValue=<someUserId>
>>>>>
>>>>>
>>>>> This will return nothing if the other ID is not a friend, the
>>>>> current user
>>>>> if the two are friends. filterValue may take a specific person
>>>>> identifier of
>>>>> @owner or @viewer.
>>>>>
>>>>> "
>>>>>
>>>>> Which implies that filtering on the *single* @me/@self entity is
>>>>> the way to
>>>>> find if the current user is friends with the specified user.
>>>>>
>>>>> Back in the early thread, (about a week ago) I think I said the
>>>>> spec looked
>>>>> odd.
>>>>>
>>>>> This is where the original URL that started this thread comes
>>>>> from.
>>>>> ---------------------------
>>>>>
>>>>> So a question for you, Chris,
>>>>> should /people/@me/@self respond to filtering?
>>>>>
>>>>>
>>>>>
>>>>> Ian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 13 Feb 2009, at 12:58, Chris Chabot wrote:
>>>>>
>>>>> There's really no need to assume anything, /people/@me/@self is
>>>>> a single
>>>>>> entity and can never be more then one result.
>>>>>>
>>>>>> Hence filtering is a bit silly, what exactly would you want to
>>>>>> filter on,
>>>>>> what would be the use-case for wanting to know a viewer *only if
>>>>>> <condition>* ?
>>>>>>
>>>>>> The only situation in which /people/@me/@self returns an error
>>>>>> is when
>>>>>> your
>>>>>> using 2 legged OAuth (or anonymous read access is allowed), in
>>>>>> which case
>>>>>> the securityToken's getViewer() will throw an exception since
>>>>>> @me can't be
>>>>>> resolve to an ID in those situations.
>>>>>>
>>>>>> In every other situation, getViewer() returns an id, which is
>>>>>> used to
>>>>>> resolve @me/@self to a single user record, which is not really
>>>>>> filterable,
>>>>>> since filtering only makes sense on collections, right?
>>>>>>
>>>>>> On Fri, Feb 13, 2009 at 1:52 PM, Ian Boston <ie...@tfd.co.uk>
>>>>>> wrote:
>>>>>>
>>>>>> Can I unwind this a little please.
>>>>>>>
>>>>>>> The original patch for 904 was to introduce a change the SPI for
>>>>>>> getPerson
>>>>>>> with filtering.
>>>>>>> I argued that getPeople already provides the filtering so
>>>>>>> there was no
>>>>>>> need
>>>>>>> for a SPI change.
>>>>>>> Ben pointed out that the REST response would then be a
>>>>>>> collection which
>>>>>>> exposed a tension in the spec.
>>>>>>>
>>>>>>> Did I get that right?
>>>>>>>
>>>>>>> Lets assume for a moment that the output of the current
>>>>>>> servlet *is*
>>>>>>> correct (ie not a collection)
>>>>>>>
>>>>>>> having called getPeople check the response and emit a 404 if
>>>>>>> there are 0
>>>>>>> entries and the only entry if there is 1 (there should not be
>>>>>>> more than 1
>>>>>>> as
>>>>>>> a result of the filter). Obviously the Future needs to be
>>>>>>> wrapped to
>>>>>>> evaluate this when its needed and not before.
>>>>>>>
>>>>>>> Does that make sense?
>>>>>>>
>>>>>>> I think if they current servlet is not correct then that needs
>>>>>>> sorting
>>>>>>> out
>>>>>>> separately, but I see emails on this thread stacking up faster
>>>>>>> than I can
>>>>>>> type or think or answer the phone.
>>>>>>>
>>>>>>> Ian
>>>>>>>
>>>>>>>
>>>>>>> On 13 Feb 2009, at 12:36, Chris Chabot wrote:
>>>>>>>
>>>>>>> On Fri, Feb 13, 2009 at 1:27 PM, Ben Smith <ben.thesmith@gmail.com
>>>>>>> >
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On 13 Feb 2009, at 12:09, Chris Chabot wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> '@self' is not a collection by any definition of the word,
>>>>>>>>> it's a
>>>>>>>>> single
>>>>>>>>>
>>>>>>>>> object, hence the lack of the collection (and the lack of
>>>>>>>>> filtering,
>>>>>>>>>> there
>>>>>>>>>> is only one 'self' and that's the viewer :)
>>>>>>>>>>
>>>>>>>>>> The same goes for activities, a query on /activities/@me/
>>>>>>>>>> @self returns
>>>>>>>>>> a
>>>>>>>>>> collection of activities (since it can contain 0, 1 or many
>>>>>>>>>> results),
>>>>>>>>>> however /activities/@me/@self/<activityId> can only return
>>>>>>>>>> 0 or 1
>>>>>>>>>> results,
>>>>>>>>>> so it returns an activity record and not a RestfulCollection.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> But that's not what the spec says should happen: 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).
>>>>>>>>>
>>>>>>>>> Unless I'm reading it wrong, /@me/@self should still return
>>>>>>>>> <response><entry><person></person></entry></response>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> There are 2 parts to the definition:
>>>>>>>>
>>>>>>>> 1) 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 something could return multiple entries it has to be a
>>>>>>>> collection,
>>>>>>>> however /@me/@self is a single entry, so this doesn't apply
>>>>>>>> here
>>>>>>>>
>>>>>>>> 2) 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
>>>>>>>>
>>>>>>>> So if the query is for /@me/@self it *MUST be a single entry.*
>>>>>>>>
>>>>>>>> I think your either confused and consfusing /@me/@self with /
>>>>>>>> @me/@all
>>>>>>>> (which
>>>>>>>> is an PortableContacts way of saying /@me/@friends), or your
>>>>>>>> a believer
>>>>>>>> in
>>>>>>>> possessions and believe that our definition of a person being
>>>>>>>> a singular
>>>>>>>> entity is wrong and the spec should be changed to allow for
>>>>>>>> multiple
>>>>>>>> spirits
>>>>>>>> and/or demons in one physical body. (And i truly hope that is
>>>>>>>> not what
>>>>>>>> your
>>>>>>>> suggesting :)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I agree that filterBy=@friends&filterValue=<userId> is
>>>>>>>> confusing, but
>>>>>>>>
>>>>>>>>> filterBy=id&filterValue=<userId> would surely remove all
>>>>>>>>> people that do
>>>>>>>>> not
>>>>>>>>> have <userId> as their userId! I guess you really want a
>>>>>>>>> filterBy AND
>>>>>>>>> filterOn (or something), or explicitly name filterValue to
>>>>>>>>> filterUserIdValue
>>>>>>>>> (or something).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Filtering on /@me/@self is confusing, since it's only one
>>>>>>>>> record, what
>>>>>>>> would
>>>>>>>> you want to filter on?
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>
Re: Extension to getPerson for 0.9
Posted by Ian Boston <ie...@tfd.co.uk>.
The XML Schema was aligned with portable contacts, and a version of
that xsd is used to validate the responses.
So the response you see from the sample container *should* be correct
wrt the xsd.
Since that work was done, the xsd has moved on a small amount, but I
think the response is correct, no entry. Inspecting the xsd should be
validate that. see section 2.2 of http://www.opensocial.org/Technical-Resources/opensocial-spec-v081/restful-protocol
or
http://svn.apache.org/repos/asf/incubator/shindig/trunk/java/social-api/src/test/resources/org/apache/shindig/social/opensocial/util/opensocial.xsd
I think this says <person> can be a top level element.
Ian
On 13 Feb 2009, at 14:35, Ben Smith wrote:
> Cool.
>
> FYI. Running Jetty from trunk and going to /people/canonical/@self?
> format=xml gives the following response:
>
> <response><person>
> <id>canonical</id>
> ...
> </person></response>
>
> I'm guessing that is a bug as there is no <entry> wrapped around the
> person object?
>
> On 13 Feb 2009, at 13:47, Ian Boston wrote:
>
>> Sounds good,
>>
>> So thats a call to getPeople(....)
>> put the Future response inside another Future response that
>> unwrapps the RC<Person> into a Person... if there is one, otherwise
>> respond with a 404.
>>
>> and yes a single entry not a collection.
>>
>> Ian
>> On 13 Feb 2009, at 13:41, Chris Chabot wrote:
>>
>>> Ah right, yeah that's indeed from
>>> http://wiki.opensocial.org/index.php?title=Implementing_IS_FRIENDS_WITH
>>>
>>> In which case I guess we should respond to that one filter option
>>> in the
>>> getPerson(), however it should still be a single entry and not a
>>> collection
>>> :)
>>>
>>>
>>> On Fri, Feb 13, 2009 at 2:30 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>>
>>>> I agree filtering on a single entity is silly:
>>>> But under the table of section 7.9 of the spec at
>>>> http://opensocial-resources.googlecode.com/svn/spec/draft/REST-API.xml
>>>>
>>>> "
>>>>
>>>>
>>>> /people/@me/@self?
>>>> filterBy=@friends&filterOp=contains&filterValue=<someUserId>
>>>>
>>>>
>>>> This will return nothing if the other ID is not a friend, the
>>>> current user
>>>> if the two are friends. filterValue may take a specific person
>>>> identifier of
>>>> @owner or @viewer.
>>>>
>>>> "
>>>>
>>>> Which implies that filtering on the *single* @me/@self entity is
>>>> the way to
>>>> find if the current user is friends with the specified user.
>>>>
>>>> Back in the early thread, (about a week ago) I think I said the
>>>> spec looked
>>>> odd.
>>>>
>>>> This is where the original URL that started this thread comes from.
>>>> ---------------------------
>>>>
>>>> So a question for you, Chris,
>>>> should /people/@me/@self respond to filtering?
>>>>
>>>>
>>>>
>>>> Ian
>>>>
>>>>
>>>>
>>>>
>>>> On 13 Feb 2009, at 12:58, Chris Chabot wrote:
>>>>
>>>> There's really no need to assume anything, /people/@me/@self is a
>>>> single
>>>>> entity and can never be more then one result.
>>>>>
>>>>> Hence filtering is a bit silly, what exactly would you want to
>>>>> filter on,
>>>>> what would be the use-case for wanting to know a viewer *only if
>>>>> <condition>* ?
>>>>>
>>>>> The only situation in which /people/@me/@self returns an error
>>>>> is when
>>>>> your
>>>>> using 2 legged OAuth (or anonymous read access is allowed), in
>>>>> which case
>>>>> the securityToken's getViewer() will throw an exception since
>>>>> @me can't be
>>>>> resolve to an ID in those situations.
>>>>>
>>>>> In every other situation, getViewer() returns an id, which is
>>>>> used to
>>>>> resolve @me/@self to a single user record, which is not really
>>>>> filterable,
>>>>> since filtering only makes sense on collections, right?
>>>>>
>>>>> On Fri, Feb 13, 2009 at 1:52 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>>>>
>>>>> Can I unwind this a little please.
>>>>>>
>>>>>> The original patch for 904 was to introduce a change the SPI for
>>>>>> getPerson
>>>>>> with filtering.
>>>>>> I argued that getPeople already provides the filtering so there
>>>>>> was no
>>>>>> need
>>>>>> for a SPI change.
>>>>>> Ben pointed out that the REST response would then be a
>>>>>> collection which
>>>>>> exposed a tension in the spec.
>>>>>>
>>>>>> Did I get that right?
>>>>>>
>>>>>> Lets assume for a moment that the output of the current servlet
>>>>>> *is*
>>>>>> correct (ie not a collection)
>>>>>>
>>>>>> having called getPeople check the response and emit a 404 if
>>>>>> there are 0
>>>>>> entries and the only entry if there is 1 (there should not be
>>>>>> more than 1
>>>>>> as
>>>>>> a result of the filter). Obviously the Future needs to be
>>>>>> wrapped to
>>>>>> evaluate this when its needed and not before.
>>>>>>
>>>>>> Does that make sense?
>>>>>>
>>>>>> I think if they current servlet is not correct then that needs
>>>>>> sorting
>>>>>> out
>>>>>> separately, but I see emails on this thread stacking up faster
>>>>>> than I can
>>>>>> type or think or answer the phone.
>>>>>>
>>>>>> Ian
>>>>>>
>>>>>>
>>>>>> On 13 Feb 2009, at 12:36, Chris Chabot wrote:
>>>>>>
>>>>>> On Fri, Feb 13, 2009 at 1:27 PM, Ben Smith <ben.thesmith@gmail.com
>>>>>> >
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On 13 Feb 2009, at 12:09, Chris Chabot wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> '@self' is not a collection by any definition of the word,
>>>>>>>> it's a
>>>>>>>> single
>>>>>>>>
>>>>>>>> object, hence the lack of the collection (and the lack of
>>>>>>>> filtering,
>>>>>>>>> there
>>>>>>>>> is only one 'self' and that's the viewer :)
>>>>>>>>>
>>>>>>>>> The same goes for activities, a query on /activities/@me/
>>>>>>>>> @self returns
>>>>>>>>> a
>>>>>>>>> collection of activities (since it can contain 0, 1 or many
>>>>>>>>> results),
>>>>>>>>> however /activities/@me/@self/<activityId> can only return 0
>>>>>>>>> or 1
>>>>>>>>> results,
>>>>>>>>> so it returns an activity record and not a RestfulCollection.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> But that's not what the spec says should happen: 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).
>>>>>>>>
>>>>>>>> Unless I'm reading it wrong, /@me/@self should still return
>>>>>>>> <response><entry><person></person></entry></response>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> There are 2 parts to the definition:
>>>>>>>
>>>>>>> 1) 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 something could return multiple entries it has to be a
>>>>>>> collection,
>>>>>>> however /@me/@self is a single entry, so this doesn't apply here
>>>>>>>
>>>>>>> 2) 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
>>>>>>>
>>>>>>> So if the query is for /@me/@self it *MUST be a single entry.*
>>>>>>>
>>>>>>> I think your either confused and consfusing /@me/@self with /
>>>>>>> @me/@all
>>>>>>> (which
>>>>>>> is an PortableContacts way of saying /@me/@friends), or your a
>>>>>>> believer
>>>>>>> in
>>>>>>> possessions and believe that our definition of a person being
>>>>>>> a singular
>>>>>>> entity is wrong and the spec should be changed to allow for
>>>>>>> multiple
>>>>>>> spirits
>>>>>>> and/or demons in one physical body. (And i truly hope that is
>>>>>>> not what
>>>>>>> your
>>>>>>> suggesting :)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I agree that filterBy=@friends&filterValue=<userId> is
>>>>>>> confusing, but
>>>>>>>
>>>>>>>> filterBy=id&filterValue=<userId> would surely remove all
>>>>>>>> people that do
>>>>>>>> not
>>>>>>>> have <userId> as their userId! I guess you really want a
>>>>>>>> filterBy AND
>>>>>>>> filterOn (or something), or explicitly name filterValue to
>>>>>>>> filterUserIdValue
>>>>>>>> (or something).
>>>>>>>>
>>>>>>>>
>>>>>>>> Filtering on /@me/@self is confusing, since it's only one
>>>>>>>> record, what
>>>>>>> would
>>>>>>> you want to filter on?
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>
Re: Extension to getPerson for 0.9
Posted by Ben Smith <be...@gmail.com>.
Cool.
FYI. Running Jetty from trunk and going to /people/canonical/@self?
format=xml gives the following response:
<response><person>
<id>canonical</id>
...
</person></response>
I'm guessing that is a bug as there is no <entry> wrapped around the
person object?
On 13 Feb 2009, at 13:47, Ian Boston wrote:
> Sounds good,
>
> So thats a call to getPeople(....)
> put the Future response inside another Future response that unwrapps
> the RC<Person> into a Person... if there is one, otherwise respond
> with a 404.
>
> and yes a single entry not a collection.
>
> Ian
> On 13 Feb 2009, at 13:41, Chris Chabot wrote:
>
>> Ah right, yeah that's indeed from
>> http://wiki.opensocial.org/index.php?title=Implementing_IS_FRIENDS_WITH
>>
>> In which case I guess we should respond to that one filter option
>> in the
>> getPerson(), however it should still be a single entry and not a
>> collection
>> :)
>>
>>
>> On Fri, Feb 13, 2009 at 2:30 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>
>>> I agree filtering on a single entity is silly:
>>> But under the table of section 7.9 of the spec at
>>> http://opensocial-resources.googlecode.com/svn/spec/draft/REST-API.xml
>>>
>>> "
>>>
>>>
>>> /people/@me/@self?
>>> filterBy=@friends&filterOp=contains&filterValue=<someUserId>
>>>
>>>
>>> This will return nothing if the other ID is not a friend, the
>>> current user
>>> if the two are friends. filterValue may take a specific person
>>> identifier of
>>> @owner or @viewer.
>>>
>>> "
>>>
>>> Which implies that filtering on the *single* @me/@self entity is
>>> the way to
>>> find if the current user is friends with the specified user.
>>>
>>> Back in the early thread, (about a week ago) I think I said the
>>> spec looked
>>> odd.
>>>
>>> This is where the original URL that started this thread comes from.
>>> ---------------------------
>>>
>>> So a question for you, Chris,
>>> should /people/@me/@self respond to filtering?
>>>
>>>
>>>
>>> Ian
>>>
>>>
>>>
>>>
>>> On 13 Feb 2009, at 12:58, Chris Chabot wrote:
>>>
>>> There's really no need to assume anything, /people/@me/@self is a
>>> single
>>>> entity and can never be more then one result.
>>>>
>>>> Hence filtering is a bit silly, what exactly would you want to
>>>> filter on,
>>>> what would be the use-case for wanting to know a viewer *only if
>>>> <condition>* ?
>>>>
>>>> The only situation in which /people/@me/@self returns an error is
>>>> when
>>>> your
>>>> using 2 legged OAuth (or anonymous read access is allowed), in
>>>> which case
>>>> the securityToken's getViewer() will throw an exception since @me
>>>> can't be
>>>> resolve to an ID in those situations.
>>>>
>>>> In every other situation, getViewer() returns an id, which is
>>>> used to
>>>> resolve @me/@self to a single user record, which is not really
>>>> filterable,
>>>> since filtering only makes sense on collections, right?
>>>>
>>>> On Fri, Feb 13, 2009 at 1:52 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>>>
>>>> Can I unwind this a little please.
>>>>>
>>>>> The original patch for 904 was to introduce a change the SPI for
>>>>> getPerson
>>>>> with filtering.
>>>>> I argued that getPeople already provides the filtering so there
>>>>> was no
>>>>> need
>>>>> for a SPI change.
>>>>> Ben pointed out that the REST response would then be a
>>>>> collection which
>>>>> exposed a tension in the spec.
>>>>>
>>>>> Did I get that right?
>>>>>
>>>>> Lets assume for a moment that the output of the current servlet
>>>>> *is*
>>>>> correct (ie not a collection)
>>>>>
>>>>> having called getPeople check the response and emit a 404 if
>>>>> there are 0
>>>>> entries and the only entry if there is 1 (there should not be
>>>>> more than 1
>>>>> as
>>>>> a result of the filter). Obviously the Future needs to be
>>>>> wrapped to
>>>>> evaluate this when its needed and not before.
>>>>>
>>>>> Does that make sense?
>>>>>
>>>>> I think if they current servlet is not correct then that needs
>>>>> sorting
>>>>> out
>>>>> separately, but I see emails on this thread stacking up faster
>>>>> than I can
>>>>> type or think or answer the phone.
>>>>>
>>>>> Ian
>>>>>
>>>>>
>>>>> On 13 Feb 2009, at 12:36, Chris Chabot wrote:
>>>>>
>>>>> On Fri, Feb 13, 2009 at 1:27 PM, Ben Smith
>>>>> <be...@gmail.com>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> On 13 Feb 2009, at 12:09, Chris Chabot wrote:
>>>>>>
>>>>>>>
>>>>>>> '@self' is not a collection by any definition of the word,
>>>>>>> it's a
>>>>>>> single
>>>>>>>
>>>>>>> object, hence the lack of the collection (and the lack of
>>>>>>> filtering,
>>>>>>>> there
>>>>>>>> is only one 'self' and that's the viewer :)
>>>>>>>>
>>>>>>>> The same goes for activities, a query on /activities/@me/
>>>>>>>> @self returns
>>>>>>>> a
>>>>>>>> collection of activities (since it can contain 0, 1 or many
>>>>>>>> results),
>>>>>>>> however /activities/@me/@self/<activityId> can only return 0
>>>>>>>> or 1
>>>>>>>> results,
>>>>>>>> so it returns an activity record and not a RestfulCollection.
>>>>>>>>
>>>>>>>>
>>>>>>>> But that's not what the spec says should happen: 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).
>>>>>>>
>>>>>>> Unless I'm reading it wrong, /@me/@self should still return
>>>>>>> <response><entry><person></person></entry></response>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> There are 2 parts to the definition:
>>>>>>
>>>>>> 1) 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 something could return multiple entries it has to be a
>>>>>> collection,
>>>>>> however /@me/@self is a single entry, so this doesn't apply here
>>>>>>
>>>>>> 2) 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
>>>>>>
>>>>>> So if the query is for /@me/@self it *MUST be a single entry.*
>>>>>>
>>>>>> I think your either confused and consfusing /@me/@self with /
>>>>>> @me/@all
>>>>>> (which
>>>>>> is an PortableContacts way of saying /@me/@friends), or your a
>>>>>> believer
>>>>>> in
>>>>>> possessions and believe that our definition of a person being a
>>>>>> singular
>>>>>> entity is wrong and the spec should be changed to allow for
>>>>>> multiple
>>>>>> spirits
>>>>>> and/or demons in one physical body. (And i truly hope that is
>>>>>> not what
>>>>>> your
>>>>>> suggesting :)
>>>>>>
>>>>>>
>>>>>>
>>>>>> I agree that filterBy=@friends&filterValue=<userId> is
>>>>>> confusing, but
>>>>>>
>>>>>>> filterBy=id&filterValue=<userId> would surely remove all
>>>>>>> people that do
>>>>>>> not
>>>>>>> have <userId> as their userId! I guess you really want a
>>>>>>> filterBy AND
>>>>>>> filterOn (or something), or explicitly name filterValue to
>>>>>>> filterUserIdValue
>>>>>>> (or something).
>>>>>>>
>>>>>>>
>>>>>>> Filtering on /@me/@self is confusing, since it's only one
>>>>>>> record, what
>>>>>> would
>>>>>> you want to filter on?
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>
Re: Extension to getPerson for 0.9
Posted by Ian Boston <ie...@tfd.co.uk>.
Sounds good,
So thats a call to getPeople(....)
put the Future response inside another Future response that unwrapps
the RC<Person> into a Person... if there is one, otherwise respond
with a 404.
and yes a single entry not a collection.
Ian
On 13 Feb 2009, at 13:41, Chris Chabot wrote:
> Ah right, yeah that's indeed from
> http://wiki.opensocial.org/index.php?
> title=Implementing_IS_FRIENDS_WITH
>
> In which case I guess we should respond to that one filter option in
> the
> getPerson(), however it should still be a single entry and not a
> collection
> :)
>
>
> On Fri, Feb 13, 2009 at 2:30 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>
>> I agree filtering on a single entity is silly:
>> But under the table of section 7.9 of the spec at
>> http://opensocial-resources.googlecode.com/svn/spec/draft/REST-
>> API.xml
>>
>> "
>>
>>
>> /people/@me/@self?
>> filterBy=@friends&filterOp=contains&filterValue=<someUserId>
>>
>>
>> This will return nothing if the other ID is not a friend, the
>> current user
>> if the two are friends. filterValue may take a specific person
>> identifier of
>> @owner or @viewer.
>>
>> "
>>
>> Which implies that filtering on the *single* @me/@self entity is
>> the way to
>> find if the current user is friends with the specified user.
>>
>> Back in the early thread, (about a week ago) I think I said the
>> spec looked
>> odd.
>>
>> This is where the original URL that started this thread comes from.
>> ---------------------------
>>
>> So a question for you, Chris,
>> should /people/@me/@self respond to filtering?
>>
>>
>>
>> Ian
>>
>>
>>
>>
>> On 13 Feb 2009, at 12:58, Chris Chabot wrote:
>>
>> There's really no need to assume anything, /people/@me/@self is a
>> single
>>> entity and can never be more then one result.
>>>
>>> Hence filtering is a bit silly, what exactly would you want to
>>> filter on,
>>> what would be the use-case for wanting to know a viewer *only if
>>> <condition>* ?
>>>
>>> The only situation in which /people/@me/@self returns an error is
>>> when
>>> your
>>> using 2 legged OAuth (or anonymous read access is allowed), in
>>> which case
>>> the securityToken's getViewer() will throw an exception since @me
>>> can't be
>>> resolve to an ID in those situations.
>>>
>>> In every other situation, getViewer() returns an id, which is used
>>> to
>>> resolve @me/@self to a single user record, which is not really
>>> filterable,
>>> since filtering only makes sense on collections, right?
>>>
>>> On Fri, Feb 13, 2009 at 1:52 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>>
>>> Can I unwind this a little please.
>>>>
>>>> The original patch for 904 was to introduce a change the SPI for
>>>> getPerson
>>>> with filtering.
>>>> I argued that getPeople already provides the filtering so there
>>>> was no
>>>> need
>>>> for a SPI change.
>>>> Ben pointed out that the REST response would then be a collection
>>>> which
>>>> exposed a tension in the spec.
>>>>
>>>> Did I get that right?
>>>>
>>>> Lets assume for a moment that the output of the current servlet
>>>> *is*
>>>> correct (ie not a collection)
>>>>
>>>> having called getPeople check the response and emit a 404 if
>>>> there are 0
>>>> entries and the only entry if there is 1 (there should not be
>>>> more than 1
>>>> as
>>>> a result of the filter). Obviously the Future needs to be wrapped
>>>> to
>>>> evaluate this when its needed and not before.
>>>>
>>>> Does that make sense?
>>>>
>>>> I think if they current servlet is not correct then that needs
>>>> sorting
>>>> out
>>>> separately, but I see emails on this thread stacking up faster
>>>> than I can
>>>> type or think or answer the phone.
>>>>
>>>> Ian
>>>>
>>>>
>>>> On 13 Feb 2009, at 12:36, Chris Chabot wrote:
>>>>
>>>> On Fri, Feb 13, 2009 at 1:27 PM, Ben Smith <be...@gmail.com>
>>>>
>>>>> wrote:
>>>>>
>>>>> On 13 Feb 2009, at 12:09, Chris Chabot wrote:
>>>>>
>>>>>>
>>>>>> '@self' is not a collection by any definition of the word, it's a
>>>>>> single
>>>>>>
>>>>>> object, hence the lack of the collection (and the lack of
>>>>>> filtering,
>>>>>>> there
>>>>>>> is only one 'self' and that's the viewer :)
>>>>>>>
>>>>>>> The same goes for activities, a query on /activities/@me/@self
>>>>>>> returns
>>>>>>> a
>>>>>>> collection of activities (since it can contain 0, 1 or many
>>>>>>> results),
>>>>>>> however /activities/@me/@self/<activityId> can only return 0
>>>>>>> or 1
>>>>>>> results,
>>>>>>> so it returns an activity record and not a RestfulCollection.
>>>>>>>
>>>>>>>
>>>>>>> But that's not what the spec says should happen: 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).
>>>>>>
>>>>>> Unless I'm reading it wrong, /@me/@self should still return
>>>>>> <response><entry><person></person></entry></response>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> There are 2 parts to the definition:
>>>>>
>>>>> 1) 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 something could return multiple entries it has to be a
>>>>> collection,
>>>>> however /@me/@self is a single entry, so this doesn't apply here
>>>>>
>>>>> 2) 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
>>>>>
>>>>> So if the query is for /@me/@self it *MUST be a single entry.*
>>>>>
>>>>> I think your either confused and consfusing /@me/@self with /@me/
>>>>> @all
>>>>> (which
>>>>> is an PortableContacts way of saying /@me/@friends), or your a
>>>>> believer
>>>>> in
>>>>> possessions and believe that our definition of a person being a
>>>>> singular
>>>>> entity is wrong and the spec should be changed to allow for
>>>>> multiple
>>>>> spirits
>>>>> and/or demons in one physical body. (And i truly hope that is
>>>>> not what
>>>>> your
>>>>> suggesting :)
>>>>>
>>>>>
>>>>>
>>>>> I agree that filterBy=@friends&filterValue=<userId> is
>>>>> confusing, but
>>>>>
>>>>>> filterBy=id&filterValue=<userId> would surely remove all people
>>>>>> that do
>>>>>> not
>>>>>> have <userId> as their userId! I guess you really want a
>>>>>> filterBy AND
>>>>>> filterOn (or something), or explicitly name filterValue to
>>>>>> filterUserIdValue
>>>>>> (or something).
>>>>>>
>>>>>>
>>>>>> Filtering on /@me/@self is confusing, since it's only one
>>>>>> record, what
>>>>> would
>>>>> you want to filter on?
>>>>>
>>>>>
>>>>
>>>>
>>
Re: Extension to getPerson for 0.9
Posted by Chris Chabot <ch...@google.com>.
Ah right, yeah that's indeed from
http://wiki.opensocial.org/index.php?title=Implementing_IS_FRIENDS_WITH
In which case I guess we should respond to that one filter option in the
getPerson(), however it should still be a single entry and not a collection
:)
On Fri, Feb 13, 2009 at 2:30 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> I agree filtering on a single entity is silly:
> But under the table of section 7.9 of the spec at
> http://opensocial-resources.googlecode.com/svn/spec/draft/REST-API.xml
>
> "
>
>
> /people/@me/@self?filterBy=@friends&filterOp=contains&filterValue=<someUserId>
>
>
> This will return nothing if the other ID is not a friend, the current user
> if the two are friends. filterValue may take a specific person identifier of
> @owner or @viewer.
>
> "
>
> Which implies that filtering on the *single* @me/@self entity is the way to
> find if the current user is friends with the specified user.
>
> Back in the early thread, (about a week ago) I think I said the spec looked
> odd.
>
> This is where the original URL that started this thread comes from.
> ---------------------------
>
> So a question for you, Chris,
> should /people/@me/@self respond to filtering?
>
>
>
> Ian
>
>
>
>
> On 13 Feb 2009, at 12:58, Chris Chabot wrote:
>
> There's really no need to assume anything, /people/@me/@self is a single
>> entity and can never be more then one result.
>>
>> Hence filtering is a bit silly, what exactly would you want to filter on,
>> what would be the use-case for wanting to know a viewer *only if
>> <condition>* ?
>>
>> The only situation in which /people/@me/@self returns an error is when
>> your
>> using 2 legged OAuth (or anonymous read access is allowed), in which case
>> the securityToken's getViewer() will throw an exception since @me can't be
>> resolve to an ID in those situations.
>>
>> In every other situation, getViewer() returns an id, which is used to
>> resolve @me/@self to a single user record, which is not really filterable,
>> since filtering only makes sense on collections, right?
>>
>> On Fri, Feb 13, 2009 at 1:52 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>
>> Can I unwind this a little please.
>>>
>>> The original patch for 904 was to introduce a change the SPI for
>>> getPerson
>>> with filtering.
>>> I argued that getPeople already provides the filtering so there was no
>>> need
>>> for a SPI change.
>>> Ben pointed out that the REST response would then be a collection which
>>> exposed a tension in the spec.
>>>
>>> Did I get that right?
>>>
>>> Lets assume for a moment that the output of the current servlet *is*
>>> correct (ie not a collection)
>>>
>>> having called getPeople check the response and emit a 404 if there are 0
>>> entries and the only entry if there is 1 (there should not be more than 1
>>> as
>>> a result of the filter). Obviously the Future needs to be wrapped to
>>> evaluate this when its needed and not before.
>>>
>>> Does that make sense?
>>>
>>> I think if they current servlet is not correct then that needs sorting
>>> out
>>> separately, but I see emails on this thread stacking up faster than I can
>>> type or think or answer the phone.
>>>
>>> Ian
>>>
>>>
>>> On 13 Feb 2009, at 12:36, Chris Chabot wrote:
>>>
>>> On Fri, Feb 13, 2009 at 1:27 PM, Ben Smith <be...@gmail.com>
>>>
>>>> wrote:
>>>>
>>>> On 13 Feb 2009, at 12:09, Chris Chabot wrote:
>>>>
>>>>>
>>>>> '@self' is not a collection by any definition of the word, it's a
>>>>> single
>>>>>
>>>>> object, hence the lack of the collection (and the lack of filtering,
>>>>>> there
>>>>>> is only one 'self' and that's the viewer :)
>>>>>>
>>>>>> The same goes for activities, a query on /activities/@me/@self returns
>>>>>> a
>>>>>> collection of activities (since it can contain 0, 1 or many results),
>>>>>> however /activities/@me/@self/<activityId> can only return 0 or 1
>>>>>> results,
>>>>>> so it returns an activity record and not a RestfulCollection.
>>>>>>
>>>>>>
>>>>>> But that's not what the spec says should happen: 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).
>>>>>
>>>>> Unless I'm reading it wrong, /@me/@self should still return
>>>>> <response><entry><person></person></entry></response>
>>>>>
>>>>>
>>>>
>>>>
>>>> There are 2 parts to the definition:
>>>>
>>>> 1) 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 something could return multiple entries it has to be a collection,
>>>> however /@me/@self is a single entry, so this doesn't apply here
>>>>
>>>> 2) 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
>>>>
>>>> So if the query is for /@me/@self it *MUST be a single entry.*
>>>>
>>>> I think your either confused and consfusing /@me/@self with /@me/@all
>>>> (which
>>>> is an PortableContacts way of saying /@me/@friends), or your a believer
>>>> in
>>>> possessions and believe that our definition of a person being a singular
>>>> entity is wrong and the spec should be changed to allow for multiple
>>>> spirits
>>>> and/or demons in one physical body. (And i truly hope that is not what
>>>> your
>>>> suggesting :)
>>>>
>>>>
>>>>
>>>> I agree that filterBy=@friends&filterValue=<userId> is confusing, but
>>>>
>>>>> filterBy=id&filterValue=<userId> would surely remove all people that do
>>>>> not
>>>>> have <userId> as their userId! I guess you really want a filterBy AND
>>>>> filterOn (or something), or explicitly name filterValue to
>>>>> filterUserIdValue
>>>>> (or something).
>>>>>
>>>>>
>>>>> Filtering on /@me/@self is confusing, since it's only one record, what
>>>> would
>>>> you want to filter on?
>>>>
>>>>
>>>
>>>
>
Re: Extension to getPerson for 0.9
Posted by Ian Boston <ie...@tfd.co.uk>.
I agree filtering on a single entity is silly:
But under the table of section 7.9 of the spec at
http://opensocial-resources.googlecode.com/svn/spec/draft/REST-API.xml
"
/people/@me/@self?
filterBy=@friends&filterOp=contains&filterValue=<someUserId>
This will return nothing if the other ID is not a friend, the current
user if the two are friends. filterValue may take a specific person
identifier of @owner or @viewer.
"
Which implies that filtering on the *single* @me/@self entity is the
way to find if the current user is friends with the specified user.
Back in the early thread, (about a week ago) I think I said the spec
looked odd.
This is where the original URL that started this thread comes from.
---------------------------
So a question for you, Chris,
should /people/@me/@self respond to filtering?
Ian
On 13 Feb 2009, at 12:58, Chris Chabot wrote:
> There's really no need to assume anything, /people/@me/@self is a
> single
> entity and can never be more then one result.
>
> Hence filtering is a bit silly, what exactly would you want to
> filter on,
> what would be the use-case for wanting to know a viewer *only if
> <condition>* ?
>
> The only situation in which /people/@me/@self returns an error is
> when your
> using 2 legged OAuth (or anonymous read access is allowed), in which
> case
> the securityToken's getViewer() will throw an exception since @me
> can't be
> resolve to an ID in those situations.
>
> In every other situation, getViewer() returns an id, which is used to
> resolve @me/@self to a single user record, which is not really
> filterable,
> since filtering only makes sense on collections, right?
>
> On Fri, Feb 13, 2009 at 1:52 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>
>> Can I unwind this a little please.
>>
>> The original patch for 904 was to introduce a change the SPI for
>> getPerson
>> with filtering.
>> I argued that getPeople already provides the filtering so there was
>> no need
>> for a SPI change.
>> Ben pointed out that the REST response would then be a collection
>> which
>> exposed a tension in the spec.
>>
>> Did I get that right?
>>
>> Lets assume for a moment that the output of the current servlet *is*
>> correct (ie not a collection)
>>
>> having called getPeople check the response and emit a 404 if there
>> are 0
>> entries and the only entry if there is 1 (there should not be more
>> than 1 as
>> a result of the filter). Obviously the Future needs to be wrapped to
>> evaluate this when its needed and not before.
>>
>> Does that make sense?
>>
>> I think if they current servlet is not correct then that needs
>> sorting out
>> separately, but I see emails on this thread stacking up faster than
>> I can
>> type or think or answer the phone.
>>
>> Ian
>>
>>
>> On 13 Feb 2009, at 12:36, Chris Chabot wrote:
>>
>> On Fri, Feb 13, 2009 at 1:27 PM, Ben Smith <be...@gmail.com>
>>> wrote:
>>>
>>> On 13 Feb 2009, at 12:09, Chris Chabot wrote:
>>>>
>>>> '@self' is not a collection by any definition of the word, it's a
>>>> single
>>>>
>>>>> object, hence the lack of the collection (and the lack of
>>>>> filtering,
>>>>> there
>>>>> is only one 'self' and that's the viewer :)
>>>>>
>>>>> The same goes for activities, a query on /activities/@me/@self
>>>>> returns a
>>>>> collection of activities (since it can contain 0, 1 or many
>>>>> results),
>>>>> however /activities/@me/@self/<activityId> can only return 0 or 1
>>>>> results,
>>>>> so it returns an activity record and not a RestfulCollection.
>>>>>
>>>>>
>>>> But that's not what the spec says should happen: 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).
>>>>
>>>> Unless I'm reading it wrong, /@me/@self should still return
>>>> <response><entry><person></person></entry></response>
>>>>
>>>
>>>
>>>
>>> There are 2 parts to the definition:
>>>
>>> 1) 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 something could return multiple entries it has to be a
>>> collection,
>>> however /@me/@self is a single entry, so this doesn't apply here
>>>
>>> 2) 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
>>>
>>> So if the query is for /@me/@self it *MUST be a single entry.*
>>>
>>> I think your either confused and consfusing /@me/@self with /@me/
>>> @all
>>> (which
>>> is an PortableContacts way of saying /@me/@friends), or your a
>>> believer in
>>> possessions and believe that our definition of a person being a
>>> singular
>>> entity is wrong and the spec should be changed to allow for multiple
>>> spirits
>>> and/or demons in one physical body. (And i truly hope that is not
>>> what
>>> your
>>> suggesting :)
>>>
>>>
>>>
>>> I agree that filterBy=@friends&filterValue=<userId> is confusing,
>>> but
>>>> filterBy=id&filterValue=<userId> would surely remove all people
>>>> that do
>>>> not
>>>> have <userId> as their userId! I guess you really want a filterBy
>>>> AND
>>>> filterOn (or something), or explicitly name filterValue to
>>>> filterUserIdValue
>>>> (or something).
>>>>
>>>>
>>> Filtering on /@me/@self is confusing, since it's only one record,
>>> what
>>> would
>>> you want to filter on?
>>>
>>
>>
Re: Extension to getPerson for 0.9
Posted by Chris Chabot <ch...@google.com>.
There's really no need to assume anything, /people/@me/@self is a single
entity and can never be more then one result.
Hence filtering is a bit silly, what exactly would you want to filter on,
what would be the use-case for wanting to know a viewer *only if
<condition>* ?
The only situation in which /people/@me/@self returns an error is when your
using 2 legged OAuth (or anonymous read access is allowed), in which case
the securityToken's getViewer() will throw an exception since @me can't be
resolve to an ID in those situations.
In every other situation, getViewer() returns an id, which is used to
resolve @me/@self to a single user record, which is not really filterable,
since filtering only makes sense on collections, right?
On Fri, Feb 13, 2009 at 1:52 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> Can I unwind this a little please.
>
> The original patch for 904 was to introduce a change the SPI for getPerson
> with filtering.
> I argued that getPeople already provides the filtering so there was no need
> for a SPI change.
> Ben pointed out that the REST response would then be a collection which
> exposed a tension in the spec.
>
> Did I get that right?
>
> Lets assume for a moment that the output of the current servlet *is*
> correct (ie not a collection)
>
> having called getPeople check the response and emit a 404 if there are 0
> entries and the only entry if there is 1 (there should not be more than 1 as
> a result of the filter). Obviously the Future needs to be wrapped to
> evaluate this when its needed and not before.
>
> Does that make sense?
>
> I think if they current servlet is not correct then that needs sorting out
> separately, but I see emails on this thread stacking up faster than I can
> type or think or answer the phone.
>
> Ian
>
>
> On 13 Feb 2009, at 12:36, Chris Chabot wrote:
>
> On Fri, Feb 13, 2009 at 1:27 PM, Ben Smith <be...@gmail.com>
>> wrote:
>>
>> On 13 Feb 2009, at 12:09, Chris Chabot wrote:
>>>
>>> '@self' is not a collection by any definition of the word, it's a single
>>>
>>>> object, hence the lack of the collection (and the lack of filtering,
>>>> there
>>>> is only one 'self' and that's the viewer :)
>>>>
>>>> The same goes for activities, a query on /activities/@me/@self returns a
>>>> collection of activities (since it can contain 0, 1 or many results),
>>>> however /activities/@me/@self/<activityId> can only return 0 or 1
>>>> results,
>>>> so it returns an activity record and not a RestfulCollection.
>>>>
>>>>
>>> But that's not what the spec says should happen: 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).
>>>
>>> Unless I'm reading it wrong, /@me/@self should still return
>>> <response><entry><person></person></entry></response>
>>>
>>
>>
>>
>> There are 2 parts to the definition:
>>
>> 1) 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 something could return multiple entries it has to be a collection,
>> however /@me/@self is a single entry, so this doesn't apply here
>>
>> 2) 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
>>
>> So if the query is for /@me/@self it *MUST be a single entry.*
>>
>> I think your either confused and consfusing /@me/@self with /@me/@all
>> (which
>> is an PortableContacts way of saying /@me/@friends), or your a believer in
>> possessions and believe that our definition of a person being a singular
>> entity is wrong and the spec should be changed to allow for multiple
>> spirits
>> and/or demons in one physical body. (And i truly hope that is not what
>> your
>> suggesting :)
>>
>>
>>
>> I agree that filterBy=@friends&filterValue=<userId> is confusing, but
>>> filterBy=id&filterValue=<userId> would surely remove all people that do
>>> not
>>> have <userId> as their userId! I guess you really want a filterBy AND
>>> filterOn (or something), or explicitly name filterValue to
>>> filterUserIdValue
>>> (or something).
>>>
>>>
>> Filtering on /@me/@self is confusing, since it's only one record, what
>> would
>> you want to filter on?
>>
>
>
Re: Extension to getPerson for 0.9
Posted by Ian Boston <ie...@tfd.co.uk>.
Can I unwind this a little please.
The original patch for 904 was to introduce a change the SPI for
getPerson with filtering.
I argued that getPeople already provides the filtering so there was no
need for a SPI change.
Ben pointed out that the REST response would then be a collection
which exposed a tension in the spec.
Did I get that right?
Lets assume for a moment that the output of the current servlet *is*
correct (ie not a collection)
having called getPeople check the response and emit a 404 if there are
0 entries and the only entry if there is 1 (there should not be more
than 1 as a result of the filter). Obviously the Future needs to be
wrapped to evaluate this when its needed and not before.
Does that make sense?
I think if they current servlet is not correct then that needs sorting
out separately, but I see emails on this thread stacking up faster
than I can type or think or answer the phone.
Ian
On 13 Feb 2009, at 12:36, Chris Chabot wrote:
> On Fri, Feb 13, 2009 at 1:27 PM, Ben Smith <be...@gmail.com>
> wrote:
>
>> On 13 Feb 2009, at 12:09, Chris Chabot wrote:
>>
>> '@self' is not a collection by any definition of the word, it's a
>> single
>>> object, hence the lack of the collection (and the lack of
>>> filtering, there
>>> is only one 'self' and that's the viewer :)
>>>
>>> The same goes for activities, a query on /activities/@me/@self
>>> returns a
>>> collection of activities (since it can contain 0, 1 or many
>>> results),
>>> however /activities/@me/@self/<activityId> can only return 0 or 1
>>> results,
>>> so it returns an activity record and not a RestfulCollection.
>>>
>>
>> But that's not what the spec says should happen: 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).
>>
>> Unless I'm reading it wrong, /@me/@self should still return
>> <response><entry><person></person></entry></response>
>
>
>
> There are 2 parts to the definition:
>
> 1) 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 something could return multiple entries it has to be a collection,
> however /@me/@self is a single entry, so this doesn't apply here
>
> 2) 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
>
> So if the query is for /@me/@self it *MUST be a single entry.*
>
> I think your either confused and consfusing /@me/@self with /@me/
> @all (which
> is an PortableContacts way of saying /@me/@friends), or your a
> believer in
> possessions and believe that our definition of a person being a
> singular
> entity is wrong and the spec should be changed to allow for multiple
> spirits
> and/or demons in one physical body. (And i truly hope that is not
> what your
> suggesting :)
>
>
>
>> I agree that filterBy=@friends&filterValue=<userId> is confusing, but
>> filterBy=id&filterValue=<userId> would surely remove all people
>> that do not
>> have <userId> as their userId! I guess you really want a filterBy AND
>> filterOn (or something), or explicitly name filterValue to
>> filterUserIdValue
>> (or something).
>>
>
> Filtering on /@me/@self is confusing, since it's only one record,
> what would
> you want to filter on?
Re: Extension to getPerson for 0.9
Posted by Chris Chabot <ch...@google.com>.
On Fri, Feb 13, 2009 at 1:27 PM, Ben Smith <be...@gmail.com> wrote:
> On 13 Feb 2009, at 12:09, Chris Chabot wrote:
>
> '@self' is not a collection by any definition of the word, it's a single
>> object, hence the lack of the collection (and the lack of filtering, there
>> is only one 'self' and that's the viewer :)
>>
>> The same goes for activities, a query on /activities/@me/@self returns a
>> collection of activities (since it can contain 0, 1 or many results),
>> however /activities/@me/@self/<activityId> can only return 0 or 1 results,
>> so it returns an activity record and not a RestfulCollection.
>>
>
> But that's not what the spec says should happen: 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).
>
> Unless I'm reading it wrong, /@me/@self should still return
> <response><entry><person></person></entry></response>
There are 2 parts to the definition:
1) 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 something could return multiple entries it has to be a collection,
however /@me/@self is a single entry, so this doesn't apply here
2) 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
So if the query is for /@me/@self it *MUST be a single entry.*
I think your either confused and consfusing /@me/@self with /@me/@all (which
is an PortableContacts way of saying /@me/@friends), or your a believer in
possessions and believe that our definition of a person being a singular
entity is wrong and the spec should be changed to allow for multiple spirits
and/or demons in one physical body. (And i truly hope that is not what your
suggesting :)
> I agree that filterBy=@friends&filterValue=<userId> is confusing, but
> filterBy=id&filterValue=<userId> would surely remove all people that do not
> have <userId> as their userId! I guess you really want a filterBy AND
> filterOn (or something), or explicitly name filterValue to filterUserIdValue
> (or something).
>
Filtering on /@me/@self is confusing, since it's only one record, what would
you want to filter on?
Re: Extension to getPerson for 0.9
Posted by Ben Smith <be...@gmail.com>.
On 13 Feb 2009, at 12:09, Chris Chabot wrote:
> '@self' is not a collection by any definition of the word, it's a
> single
> object, hence the lack of the collection (and the lack of filtering,
> there
> is only one 'self' and that's the viewer :)
>
> The same goes for activities, a query on /activities/@me/@self
> returns a
> collection of activities (since it can contain 0, 1 or many results),
> however /activities/@me/@self/<activityId> can only return 0 or 1
> results,
> so it returns an activity record and not a RestfulCollection.
But that's not what the spec says should happen: 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).
Unless I'm reading it wrong, /@me/@self should still return
<response><entry><person></person></entry></response>
> Even if you could do
> /people/@me/@self?
> filterBy=@friends&filterOp=contains&filterValue=<someUserId>
> it would *always* return an empty result set *unless* the social
> networking
> site allows for schizophrenic relationships and allowed you to
> befriend
> and/or unfriend your self :)
>
> Really i think the query your looking for is /people/@me/@self/
> <userId>,
> which tells you if a person is a friend of '@me' or not (and returns a
> single record), or
> /people/@me/@friends?
> filterBy=id&filterOp=contains&filterValue=<userId>,
> which returns a collection with a 0 or 1 entries in it.
I agree that filterBy=@friends&filterValue=<userId> is confusing, but
filterBy=id&filterValue=<userId> would surely remove all people that
do not have <userId> as their userId! I guess you really want a
filterBy AND filterOn (or something), or explicitly name filterValue
to filterUserIdValue (or something).
> On Fri, Feb 13, 2009 at 12:56 PM, Ben Smith <be...@gmail.com>
> 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?
>>>> filterBy=@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
>>>>
>>>>
>>>>
>>>
>>
Re: Extension to getPerson for 0.9
Posted by Chris Chabot <ch...@google.com>.
On Fri, Feb 13, 2009 at 1:09 PM, Chris Chabot <ch...@google.com> wrote:
> '@self' is not a collection by any definition of the word, it's a single
> object, hence the lack of the collection (and the lack of filtering, there
> is only one 'self' and that's the viewer :)
>
> The same goes for activities, a query on /activities/@me/@self returns a
> collection of activities (since it can contain 0, 1 or many results),
> however /activities/@me/@self/<activityId> can only return 0 or 1 results,
> so it returns an activity record and not a RestfulCollection.
>
> Even if you could do
> /people/@me/@self?filterBy=@friends&filterOp=contains&filterValue=<someUserId>
> it would *always* return an empty result set *unless* the social networking
> site allows for schizophrenic relationships and allowed you to befriend
> and/or unfriend your self :)
>
> Really i think the query your looking for is */people/@me/@self/<userId>*,
> which tells you if a person is a friend of '@me' or not (and returns a
> single record), or
> /people/@me/@friends?filterBy=id&filterOp=contains&filterValue=<userId>,
> which returns a collection with a 0 or 1 entries in it.
>
doh i confused my self, that's supposed to be:*/people/@me/@friends/<userId>
*
>
>
>
> On Fri, Feb 13, 2009 at 12:56 PM, Ben Smith <be...@gmail.com>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?filterBy=@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
>>>>
>>>>
>>>>
>>>
>>
>
Re: Extension to getPerson for 0.9
Posted by Chris Chabot <ch...@google.com>.
'@self' is not a collection by any definition of the word, it's a single
object, hence the lack of the collection (and the lack of filtering, there
is only one 'self' and that's the viewer :)
The same goes for activities, a query on /activities/@me/@self returns a
collection of activities (since it can contain 0, 1 or many results),
however /activities/@me/@self/<activityId> can only return 0 or 1 results,
so it returns an activity record and not a RestfulCollection.
Even if you could do
/people/@me/@self?filterBy=@friends&filterOp=contains&filterValue=<someUserId>
it would *always* return an empty result set *unless* the social networking
site allows for schizophrenic relationships and allowed you to befriend
and/or unfriend your self :)
Really i think the query your looking for is /people/@me/@self/<userId>,
which tells you if a person is a friend of '@me' or not (and returns a
single record), or
/people/@me/@friends?filterBy=id&filterOp=contains&filterValue=<userId>,
which returns a collection with a 0 or 1 entries in it.
On Fri, Feb 13, 2009 at 12:56 PM, Ben Smith <be...@gmail.com> 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?filterBy=@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
>>>
>>>
>>>
>>
>
Re: Extension to getPerson for 0.9
Posted by Chris Chabot <ch...@google.com>.
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 <ch...@google.com> 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 <be...@gmail.com> 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 <ie...@tfd.co.uk> 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?filterBy=@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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>
Re: Extension to getPerson for 0.9
Posted by Chris Chabot <ch...@google.com>.
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 <be...@gmail.com> 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 <ie...@tfd.co.uk> 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?filterBy=@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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
Re: Extension to getPerson for 0.9
Posted by Ben Smith <be...@gmail.com>.
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 <ie...@tfd.co.uk> 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?
>>>>> filterBy=@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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
Re: Extension to getPerson for 0.9
Posted by Ian Boston <ie...@tfd.co.uk>.
Chris, sorry I was on the phone, your first response didn't get to my
inbox before I sent my reply to Ben. I guess my email client had
stalled, iMail does that sometimes connected to google imap, they were
only 5 minutes apart.
Looks like Ben is replying to your messages so I will go and read that
first.
Ian
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
>
> 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.
>
>
>
> On Fri, Feb 13, 2009 at 1:18 PM, Ian Boston <ie...@tfd.co.uk> 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?
>>>>> filterBy=@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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
Re: Extension to getPerson for 0.9
Posted by Chris Chabot <ch...@google.com>.
Guys am I on your spam lists and getting redirected to /dev/null or
something? I feel a bit ignored
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.
On Fri, Feb 13, 2009 at 1:18 PM, Ian Boston <ie...@tfd.co.uk> 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?filterBy=@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
>>>>
>>>>
>>>>
>>>
>>
>
Re: Extension to getPerson for 0.9
Posted by Ian Boston <ie...@tfd.co.uk>.
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?
>>> filterBy=@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
>>>
>>>
>>
>
Re: Extension to getPerson for 0.9
Posted by Ben Smith <be...@gmail.com>.
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?
>> filterBy=@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
>>
>>
>
Re: Extension to getPerson for 0.9
Posted by Ian Boston <ie...@tfd.co.uk>.
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?
> filterBy=@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
>
>
Re: Extension to getPerson for 0.9
Posted by Chris Chabot <ch...@google.com>.
Doesn't the query
/people/@me/@friends?filterBy=id&filterOp=containers&filterValue=<userId>
make more sense?
or if your looking to see if a specific userId is a friend of '@me', why not
do a get on:
/people/@me/@friends/<userId>
if that returns a 404, it's not a friend.. if you get a record back, (s)he
is a friend
On Fri, Feb 13, 2009 at 12:32 PM, Ben Smith <be...@gmail.com> 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?filterBy=@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
>
>
>