You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Alejandro Rivero <al...@gmail.com> on 2008/05/05 00:13:36 UTC
fetchpeople/fetchperson and USER_IDS
In http://code.google.com/apis/opensocial/articles/datarequests/datarequests-0.7.html
the author tells about "... newFetchPersonRequest() method, passing
in an idSpec argument and, optionally, an object specifying pertinent
parameters such as the extended profile fields to return with the
person. The idSpec can be the OWNER or VIEWER constants discussed
above or a single OpenSocial ID string. "
and also about "...newFetchPeopleRequest() method, passing in an
idSpec argument and, optionally, an object specifying pertinent
parameters. The idSpec here can be either OWNER_FRIENDS or
VIEWER_FRIENDS (as covered above) or an array of OpenSocial ID strings
for fetching specific individuals"
I am not sure if shindig supports this. We get a response "The json
request had a bad idSpec" for any combination we try.
In the model, the public class IdSpec does not seem to react well to
the case USER_IDS. The hack
if (idSpecEnum == null) {idSpecEnum = Type.USER_IDS; }
never applies, because IllegalArgumentException is thrown.
GadgetDataHandler gets it, and raises the response "bad idSpec"
Can anyone provide an example of a working USER_IDS request?
Alejandro
Re: fetchpeople/fetchperson and USER_IDS
Posted by Cassie <do...@apache.org>.
No problem at all :)
Let us know if you have any problems with the latest fixes.
Thanks.
- Cassie
On Mon, May 5, 2008 at 4:28 PM, Alejandro Rivero <al...@gmail.com>
wrote:
> Thanks very much! Now I am definitely forced to update the system :-)
> Well, I expect all this confusion between methods FetchPeople and
> FetchPerson will evolve as we approach to Opensocial 0.99...
>
> Probably nobody was worried because the only way to get UserIds is
> from the activity data, and some containers do not provide activity
> streams, due to security restrictions. But it is clear that shindig
> should try to be the most general implementation.
>
> Let me apologize by bringing up the question also in the general list;
> We plan to deploy our gadgets (Luis' ones, plus some others) in more
> containers besides ours, so I was a bit worried.
>
> Alejandro
>
> 2008/5/5 Cassie <do...@apache.org>:
> > this is just a bug in the current impl, i will fix it now.
> > thanks for finding it!
> >
> > - cassie
> >
> >
> > On Mon, May 5, 2008 at 12:13 AM, Alejandro Rivero <al...@gmail.com>
> > wrote:
> >
> >
> >
> > > In
> > >
> http://code.google.com/apis/opensocial/articles/datarequests/datarequests-0.7.html
> > > the author tells about "... newFetchPersonRequest() method, passing
> > > in an idSpec argument and, optionally, an object specifying pertinent
> > > parameters such as the extended profile fields to return with the
> > > person. The idSpec can be the OWNER or VIEWER constants discussed
> > > above or a single OpenSocial ID string. "
> > > and also about "...newFetchPeopleRequest() method, passing in an
> > > idSpec argument and, optionally, an object specifying pertinent
> > > parameters. The idSpec here can be either OWNER_FRIENDS or
> > > VIEWER_FRIENDS (as covered above) or an array of OpenSocial ID strings
> > > for fetching specific individuals"
> > >
> > > I am not sure if shindig supports this. We get a response "The json
> > > request had a bad idSpec" for any combination we try.
> > >
> > > In the model, the public class IdSpec does not seem to react well to
> > > the case USER_IDS. The hack
> > > if (idSpecEnum == null) {idSpecEnum = Type.USER_IDS; }
> > > never applies, because IllegalArgumentException is thrown.
> > > GadgetDataHandler gets it, and raises the response "bad idSpec"
> > >
> > > Can anyone provide an example of a working USER_IDS request?
> > >
> > > Alejandro
> > >
> >
>
Re: fetchpeople/fetchperson and USER_IDS
Posted by Alejandro Rivero <al...@gmail.com>.
Thanks very much! Now I am definitely forced to update the system :-)
Well, I expect all this confusion between methods FetchPeople and
FetchPerson will evolve as we approach to Opensocial 0.99...
Probably nobody was worried because the only way to get UserIds is
from the activity data, and some containers do not provide activity
streams, due to security restrictions. But it is clear that shindig
should try to be the most general implementation.
Let me apologize by bringing up the question also in the general list;
We plan to deploy our gadgets (Luis' ones, plus some others) in more
containers besides ours, so I was a bit worried.
Alejandro
2008/5/5 Cassie <do...@apache.org>:
> this is just a bug in the current impl, i will fix it now.
> thanks for finding it!
>
> - cassie
>
>
> On Mon, May 5, 2008 at 12:13 AM, Alejandro Rivero <al...@gmail.com>
> wrote:
>
>
>
> > In
> > http://code.google.com/apis/opensocial/articles/datarequests/datarequests-0.7.html
> > the author tells about "... newFetchPersonRequest() method, passing
> > in an idSpec argument and, optionally, an object specifying pertinent
> > parameters such as the extended profile fields to return with the
> > person. The idSpec can be the OWNER or VIEWER constants discussed
> > above or a single OpenSocial ID string. "
> > and also about "...newFetchPeopleRequest() method, passing in an
> > idSpec argument and, optionally, an object specifying pertinent
> > parameters. The idSpec here can be either OWNER_FRIENDS or
> > VIEWER_FRIENDS (as covered above) or an array of OpenSocial ID strings
> > for fetching specific individuals"
> >
> > I am not sure if shindig supports this. We get a response "The json
> > request had a bad idSpec" for any combination we try.
> >
> > In the model, the public class IdSpec does not seem to react well to
> > the case USER_IDS. The hack
> > if (idSpecEnum == null) {idSpecEnum = Type.USER_IDS; }
> > never applies, because IllegalArgumentException is thrown.
> > GadgetDataHandler gets it, and raises the response "bad idSpec"
> >
> > Can anyone provide an example of a working USER_IDS request?
> >
> > Alejandro
> >
>
Re: fetchpeople/fetchperson and USER_IDS
Posted by Cassie <do...@apache.org>.
this is just a bug in the current impl, i will fix it now.
thanks for finding it!
- cassie
On Mon, May 5, 2008 at 12:13 AM, Alejandro Rivero <al...@gmail.com>
wrote:
> In
> http://code.google.com/apis/opensocial/articles/datarequests/datarequests-0.7.html
> the author tells about "... newFetchPersonRequest() method, passing
> in an idSpec argument and, optionally, an object specifying pertinent
> parameters such as the extended profile fields to return with the
> person. The idSpec can be the OWNER or VIEWER constants discussed
> above or a single OpenSocial ID string. "
> and also about "...newFetchPeopleRequest() method, passing in an
> idSpec argument and, optionally, an object specifying pertinent
> parameters. The idSpec here can be either OWNER_FRIENDS or
> VIEWER_FRIENDS (as covered above) or an array of OpenSocial ID strings
> for fetching specific individuals"
>
> I am not sure if shindig supports this. We get a response "The json
> request had a bad idSpec" for any combination we try.
>
> In the model, the public class IdSpec does not seem to react well to
> the case USER_IDS. The hack
> if (idSpecEnum == null) {idSpecEnum = Type.USER_IDS; }
> never applies, because IllegalArgumentException is thrown.
> GadgetDataHandler gets it, and raises the response "bad idSpec"
>
> Can anyone provide an example of a working USER_IDS request?
>
> Alejandro
>