All sounds pretty reasonable. I'm going to have to bow out and let the
committers come to the right decision. There is a patch for either
option (that will probably need updating).
Let me know what you decide.
Ben
On 20 Feb 2009, at 16:50, Adam Winer wrote:
This breaks the interface in a worse way, and leaves the APIs broken
going
forward - one method that doesn't get called, and one method that
*thinks*
its returning a collection, but really isn't in some undocumented
cases. I
know it broke our servers when we upgraded (our implementation of
getPerson() was subtly different from getPeople(), and intentionally
so.)
Better to break APIs in a clear and simple way than do so cryptically.
We shouldn't be changing the service layer on the 1.0 branch, but we
can't
commit to API stability on trunk.
On Fri, Feb 20, 2009 at 8:06 AM, Ben Smith <[email protected]>
wrote:
That's what I suggested (and supplied a patch for) but Ian was keen
not to
break the interface for the service layer.
On 20 Feb 2009, at 16:02, Adam Winer wrote:
Speaking of this change: what got committed seems odd. For scalar
calls, PersonHandler now calls PersonService.getPeople(), and drops
all but the first result. PersonService.getPerson() is never
called.
It seems significantly cleaner to add CollectionOptions to
PersonService.getPerson() (and, perhaps, rename CollectionOptions).
Why did we go this route? Sorry that I didn't follow the discussion
the first time through.
On Fri, Feb 20, 2009 at 1:39 AM, Ben Smith <[email protected]>
wrote:
Hi Louis, sorry I missed this.
I'll make sure I do this from now on. I thought it was something
that
commiters did, sorry for the omission.
On 17 Feb 2009, at 17:40, Louis Ryan wrote:
Ben
Can you post this patch to codereview.appspot.com. Its become
working
practice to post changes that are likely to incur feedback there.
-Louis
On Sat, Feb 14, 2009 at 8:37 AM, Ben Smith (JIRA)
<[email protected]>
wrote:
[
https://issues.apache.org/jira/browse/SHINDIG-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Smith updated SHINDIG-918:
------------------------------
Attachment: SHINDIG-918-improvement.patch
Has PersonHandler call getPeople for all types of request.
Change to PersonHandler to allow filtering of requests - 0.9
improvement
------------------------------------------------------------------------
Key: SHINDIG-918
URL: https://issues.apache.org/jira/browse/
SHINDIG-918
Project: Shindig
Issue Type: Improvement
Components: Java
Affects Versions: trunk
Reporter: Ben Smith
Fix For: trunk
Attachments: SHINDIG-918-improvement.patch
Calls for single people (say, /people/@me/@self) should be
filterable:
http://opensocial-resources.googlecode.com/svn/spec/draft/REST-API.xml#standardQueryParameters
Because PersonHandler calls PersonService.getPerson() for such
requests,
which doesn't accept CollectionOptions, the result can't be
filtered. A
patch in SHINDIG-904 solved this by changing the getPerson()
method
signature but after much discussion on the mailing list it was
decided
that
a better solution would be to change PersonHandler to only call
getPeople,
and convert the RestfulCollection result to a single Person
when calls
for a
single user are made (like, /people/@me/@self).
Patch to follow.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
