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 <[email protected]>
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 filter...@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?
