That's just a 0.7/0.8 diff. I think that particular compliance test is a
little silly so we can probably ignore it. Essentially it is testing that
newFetchPerson(true) fails. Before, that used to return an error (which is
good) and now it simply returns no data. This is because of the new IdSpec.
We translate true to an idSpec with {userId: true} and then the calls think
that "true" is a perfectly fine userId and don't return an error.

Anyway, it is silly and hopefully we will have better compliance tests soon
:)

- Cassie



On Mon, Jun 16, 2008 at 9:45 PM, Chris Chabot <[EMAIL PROTECTED]> wrote:

> Indeed working perfectly, thanks for putting that in there!
>
> When running the opensocial-compliance gadget i get the same failure on
> both the java and php based rest:
> fetch people    - When passed an invalid idSpec to fetch people your code
> should not throw an exception
>
> Is that something wrong still in the error code parsing in that bit or just
> a 0.7/0.8 diff?
>
>        -- Chris
>
>
> On Jun 16, 2008, at 9:15 PM, Cassie wrote:
>
>  Yup, I read my email out of order :)
>> Error code support is in the js now. Should work seamlessly for php.
>>
>> - Cassie
>>
>>
>> On Mon, Jun 16, 2008 at 10:31 AM, Chris Chabot <[EMAIL PROTECTED]> wrote:
>>
>>  Quite well, json bit looks solid and i'm letting the concept of atom cook
>>> in my mind for a bit, json part is on the same level as the java
>>> implementation.
>>>
>>> As soon as javascript supports the http error codes it should be doing
>>> the
>>> samples as well as the old wire format :)
>>>
>>>      -- Chris
>>>
>>>
>>> On Jun 16, 2008, at 6:49 PM, Cassie wrote:
>>>
>>> Yeah - those are all the right errors and I'm about to check in a change
>>>
>>>> on
>>>> the java side that uses the right errors. The javascript doesn't
>>>> understand
>>>> them yet but I'll try to update it when I make the java change.
>>>>
>>>> How's the php restful going?
>>>>
>>>> - Cassie
>>>>
>>>>
>>>> On Sun, Jun 15, 2008 at 3:36 PM, Chris Chabot <[EMAIL PROTECTED]>
>>>> wrote:
>>>>
>>>> Hmmm that probably should've been obvious but i was staring at the old
>>>>
>>>>> wire
>>>>> format code so hard trying to make it fit together with minimal impact
>>>>> i
>>>>> kinda missed that :)
>>>>>
>>>>> Added in the appropriate places, thanks for the suggestion :)
>>>>>
>>>>>    -- Chris
>>>>>
>>>>>
>>>>> On Jun 16, 2008, at 12:07 AM, John Panzer wrote:
>>>>>
>>>>> 404 not found should be in there too
>>>>>
>>>>>
>>>>>> On 6/15/08, Chris Chabot <[EMAIL PROTECTED]> wrote:
>>>>>>
>>>>>> Ps i'm assuming for now we'll use :
>>>>>>
>>>>>>> 501 Not Implemented
>>>>>>> 401 Unauthorized
>>>>>>> 403 Forbidden
>>>>>>> 400 Bad Request
>>>>>>> 500 Internal Server Error
>>>>>>>
>>>>>>> If those assumptions are correct, the only question left is "Does the
>>>>>>> javascript side deal with these correctly?"
>>>>>>>
>>>>>>>    -- Chris
>>>>>>>
>>>>>>> On Jun 15, 2008, at 5:43 PM, Chris Chabot wrote:
>>>>>>>
>>>>>>> Since we're doing REST our error codes should be returned in http
>>>>>>>
>>>>>>>  error codes, have figured out which codes we want to return in what
>>>>>>>> situations yet, and does the features javascript support them?
>>>>>>>>
>>>>>>>> Looked at the restjson code and the handling of the ResponseItem
>>>>>>>> errors seemed to be missing
>>>>>>>>
>>>>>>>>    -- Chris
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>

Reply via email to