request of features for activity request

[Alejandro Rivero]

Hi all,

Two new issues have been open in the issue list, in order to ask for
features in the specification of the request for a list of activities.

http://code.google.com/p/opensocial-resources/issues/detail?id=141

Issue 141: Request Activities should have pagination or request
limit.

http://code.google.com/p/opensocial-resources/issues/detail?id=140
Issue 140: responseItem.getData() for "Activities" should work in the
same way that for People

#140 wording seems more generic than #140, but actually it is not. It
asks for myresponse.getData().each() and myresponse.getData().size(),
which are specified to work in People Request but are not in Activity
Requests. These request work differently, due to legacy from 0.5. Such
legacy should be removed. To me, #140 is almost a bug report, more
than a feature request.

#141 asks for an optional request limit.

Actually both issues could be fused into one, with the title of #140,
then asking also for filters and all the other features of people
requests.

In any case, please star the Issues if you are interested.

[Cassie]

Alejandro has two proposals here.

1. Get rid of the "activities" pointer in the fetchActivities request
(#140). This would have the following spec change:

instead of: (datarequest.js line 328)
* When processed, returns an object whose "activities" property is a
Collection<Activity> object.
do this:
* When processed, returns an Collection<Activity> object.

2. Add paging support to fetch activities. (#141) This would involve
adding a max, first, sortOrder and possibly filterType param as
accepted parameters into the request. Perhaps simply reusing the
pagination params that are already defined for the people fetching
methods.

Do we want to do either or both of these?
Please chime in.

Thanks.

- Cassie

[do...@google.com]

Okay, how about we simplify this proposal in order to close it for
0.8. Let's drop the paging issue and move that to 0.9 and only address
the silly legacy pointer. So..

We change this:

When processed, returns an object whose "activities" property is a

Collection<Activity>

to this:
When processed, returns a Collection<Activity>.

+1 from me.

Thanks.
- Cassie

[Arne Roomann-Kurrik (Google)]

+1 for dropping the legacy pointer.

I'm also +1 for adding max, first, filterType and sortOrder for the
activities paging methods if this is still on the table (maybe for
0.9?). I think we would need to define some new sort order and filter
types, though (for example, I'd expect default ordering to be by
TIME_DESC).

~Arne

On Apr 29, 8:04 am, d...@google.com wrote:
> Okay, how about we simplify this proposal in order to close it for
> 0.8. Let's drop the paging issue and move that to 0.9 and only address
> the silly legacy pointer. So..
>
> We change this:
> When processed, returns an object whose "activities" property is a
> Collection<Activity>
>
> to this:
> When processed, returns a Collection<Activity>.
>
> +1 from me.
>
> Thanks.
> - Cassie
>

> On 4/14/08, Cassie <d...@google.com> wrote:
>
> > Alejandro has two proposals here.
>
> > 1. Get rid of the "activities" pointer in the fetchActivities request
> > (#140). This would have the following spec change:
>
> > instead of: (datarequest.js line 328)
> > * When processed, returns an object whose "activities" property is a
> > Collection&lt;Activity&gt; object.
> > do this:
> > * When processed, returns an Collection&lt;Activity&gt; object.
>
> > 2. Add paging support to fetch activities. (#141) This would involve
> > adding a max, first, sortOrder and possibly filterType param as
> > accepted parameters into the request. Perhaps simply reusing the
> > pagination params that are already defined for the people fetching
> > methods.
>
> > Do we want to do either or both of these?
> > Please chime in.
>
> > Thanks.
>
> > - Cassie
>

> > On Wed, Apr 9, 2008 at 11:49 PM, Alejandro Rivero <Al.Riv...@gmail.com>

[Lou Moore]

+1

[Robert Evans]

+1

[Cassie]

+1
Alright, 5 votes and the simpler version is approved.
We will take up the paging stuff for 0.9.

Thanks.

- Cassie