#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.
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.
> #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.
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. 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
> On Wed, Apr 9, 2008 at 11:49 PM, Alejandro Rivero <Al.Riv...@gmail.com> > wrote:
>> 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.
>> #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.
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).
> 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. 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
> > On Wed, Apr 9, 2008 at 11:49 PM, Alejandro Rivero <Al.Riv...@gmail.com>
> > wrote:
> >> 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.
> >> #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.
> 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<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
>> > On Wed, Apr 9, 2008 at 11:49 PM, Alejandro Rivero <Al.Riv...@gmail.com> >> > wrote:
>>> >> 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.
>>> >> #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.
On Tue, Apr 29, 2008 at 7:56 PM, Lou Moore <lmo...@hi5.com> wrote: > +1
> On 4/29/08 8:04 AM, "d...@google.com" <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<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
> > On Wed, Apr 9, 2008 at 11:49 PM, Alejandro Rivero <Al.Riv...@gmail.com> > > wrote:
> >> 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.
> >> #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.
On Wed, Apr 30, 2008 at 8:07 PM, Robert Evans <bobev...@google.com> wrote: > +1
> On Tue, Apr 29, 2008 at 7:56 PM, Lou Moore <lmo...@hi5.com> wrote:
>> +1
>> On 4/29/08 8:04 AM, "d...@google.com" <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<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
>> > On Wed, Apr 9, 2008 at 11:49 PM, Alejandro Rivero <Al.Riv...@gmail.com> >> > wrote:
>> >> 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.
>> >> #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.
|
