* Proposal for Activity Paging Support in OpenSocial
* Background
We can expect that Social Network users will generate a huge number of Activities and for a variety of reasons, that clients of the OpenSocial APIs will not wish to retrieve all of these activities at once. OpenSocial must provide a way for clients to retrieve partial Activity data in pages and this proposal outlines the changes needed to the various OpenSocial specifications.
* Proposed changes
The to support Activitity Paging in the OpenSocial RESTful protocol, RPC protocol and JavaScript are outlined below.
* RESTful protocol changes
No change is necessary. Section 6.5 of the v0.8.1 RESTful protocol already specifies paging via startIndex and count for all collections returned.
* RPC protocol changes
No change is necessary. Section 8.2 of the v0.8.1 RPC protocol already specifies paging for activies via startIndex and count parameters.
* JavaScript API changes
Here, all we need to do is to provide a new static class opensocial.DataRequest.ActivityRequestFields with he following fields:
<static> object FIRST When paginating, the index of the first item to fetch; specified as a number. <static> object MAX The maximum number of items to fetch, specified as a number; defaults to 20.'
> * Proposal for Activity Paging Support in OpenSocial
> * Background
> We can expect that Social Network users will generate a huge number of > Activities and for a variety of reasons, that clients of the > OpenSocial APIs will not wish to retrieve all of these activities at > once. OpenSocial must provide a way for clients to retrieve partial > Activity data in pages and this proposal outlines the changes needed > to the various OpenSocial specifications.
> * Proposed changes
> The to support Activitity Paging in the OpenSocial RESTful protocol, > RPC protocol and JavaScript are outlined below.
> * RESTful protocol changes
> No change is necessary. Section 6.5 of the v0.8.1 RESTful protocol > already specifies paging via startIndex and count for all collections > returned.
> * RPC protocol changes
> No change is necessary. Section 8.2 of the v0.8.1 RPC protocol already > specifies paging for activies via startIndex and count parameters.
> * JavaScript API changes
> Here, all we need to do is to provide a new static class > opensocial.DataRequest.ActivityRequestFields with he following fields:
> <static> object FIRST > When paginating, the index of the first item to fetch; > specified as a number. > <static> object MAX > The maximum number of items to fetch, specified as a number; > defaults to 20.'
I'd also suggest that the spec explicitly define: (1) The default value of the "FIRST" parameter; (2) Valid ranges of "FIRST" and "MAX"; (3) Expected result when either parameter is out of range.
> * Proposal for Activity Paging Support in OpenSocial
> * Background
> We can expect that Social Network users will generate a huge number of > Activities and for a variety of reasons, that clients of the > OpenSocial APIs will not wish to retrieve all of these activities at > once. OpenSocial must provide a way for clients to retrieve partial > Activity data in pages and this proposal outlines the changes needed > to the various OpenSocial specifications.
> * Proposed changes
> The to support Activitity Paging in the OpenSocial RESTful protocol, > RPC protocol and JavaScript are outlined below.
> * RESTful protocol changes
> No change is necessary. Section 6.5 of the v0.8.1 RESTful protocol > already specifies paging via startIndex and count for all collections > returned.
> * RPC protocol changes
> No change is necessary. Section 8.2 of the v0.8.1 RPC protocol already > specifies paging for activies via startIndex and count parameters.
> * JavaScript API changes
> Here, all we need to do is to provide a new static class > opensocial.DataRequest.ActivityRequestFields with he following fields:
> <static> object FIRST > When paginating, the index of the first item to fetch; > specified as a number. > <static> object MAX > The maximum number of items to fetch, specified as a number; > defaults to 20.'
> I'd also suggest that the spec explicitly define: (1) The default value of
> the "FIRST" parameter; (2) Valid ranges of "FIRST" and "MAX"; (3) Expected
> result when either parameter is out of range.
> On Fri, Nov 7, 2008 at 9:42 AM, Dave <snoopd...@gmail.com> wrote:
> > * Proposal for Activity Paging Support in OpenSocial
> > * Background
> > We can expect that Social Network users will generate a huge number of
> > Activities and for a variety of reasons, that clients of the
> > OpenSocial APIs will not wish to retrieve all of these activities at
> > once. OpenSocial must provide a way for clients to retrieve partial
> > Activity data in pages and this proposal outlines the changes needed
> > to the various OpenSocial specifications.
> > * Proposed changes
> > The to support Activitity Paging in the OpenSocial RESTful protocol,
> > RPC protocol and JavaScript are outlined below.
> > * RESTful protocol changes
> > No change is necessary. Section 6.5 of the v0.8.1 RESTful protocol
> > already specifies paging via startIndex and count for all collections
> > returned.
> > * RPC protocol changes
> > No change is necessary. Section 8.2 of the v0.8.1 RPC protocol already
> > specifies paging for activies via startIndex and count parameters.
> > * JavaScript API changes
> > Here, all we need to do is to provide a new static class
> > opensocial.DataRequest.ActivityRequestFields with he following fields:
> > <static> object FIRST
> > When paginating, the index of the first item to fetch;
> > specified as a number.
> > <static> object MAX
> > The maximum number of items to fetch, specified as a number;
> > defaults to 20.'
On Tue, Nov 11, 2008 at 2:05 PM, Scott Seely <sse...@myspace.com> wrote:
> +1
> On Nov 7, 4:19 pm, Zhen Wang <wa...@google.com> wrote: > > +1
> > I'd also suggest that the spec explicitly define: (1) The default value > of > > the "FIRST" parameter; (2) Valid ranges of "FIRST" and "MAX"; (3) > Expected > > result when either parameter is out of range.
> > On Fri, Nov 7, 2008 at 9:42 AM, Dave <snoopd...@gmail.com> wrote:
> > > * Proposal for Activity Paging Support in OpenSocial
> > > * Background
> > > We can expect that Social Network users will generate a huge number of > > > Activities and for a variety of reasons, that clients of the > > > OpenSocial APIs will not wish to retrieve all of these activities at > > > once. OpenSocial must provide a way for clients to retrieve partial > > > Activity data in pages and this proposal outlines the changes needed > > > to the various OpenSocial specifications.
> > > * Proposed changes
> > > The to support Activitity Paging in the OpenSocial RESTful protocol, > > > RPC protocol and JavaScript are outlined below.
> > > * RESTful protocol changes
> > > No change is necessary. Section 6.5 of the v0.8.1 RESTful protocol > > > already specifies paging via startIndex and count for all collections > > > returned.
> > > * RPC protocol changes
> > > No change is necessary. Section 8.2 of the v0.8.1 RPC protocol already > > > specifies paging for activies via startIndex and count parameters.
> > > * JavaScript API changes
> > > Here, all we need to do is to provide a new static class > > > opensocial.DataRequest.ActivityRequestFields with he following fields:
> > > <static> object FIRST > > > When paginating, the index of the first item to fetch; > > > specified as a number. > > > <static> object MAX > > > The maximum number of items to fetch, specified as a number; > > > defaults to 20.'
> On Tue, Nov 11, 2008 at 2:05 PM, Scott Seely <sse...@myspace.com> wrote:
> > +1
> > On Nov 7, 4:19 pm, Zhen Wang <wa...@google.com> wrote:
> > > +1
> > > I'd also suggest that the spec explicitly define: (1) The default value
> > of
> > > the "FIRST" parameter; (2) Valid ranges of "FIRST" and "MAX"; (3)
> > Expected
> > > result when either parameter is out of range.
> > > On Fri, Nov 7, 2008 at 9:42 AM, Dave <snoopd...@gmail.com> wrote:
> > > > * Proposal for Activity Paging Support in OpenSocial
> > > > * Background
> > > > We can expect that Social Network users will generate a huge number of
> > > > Activities and for a variety of reasons, that clients of the
> > > > OpenSocial APIs will not wish to retrieve all of these activities at
> > > > once. OpenSocial must provide a way for clients to retrieve partial
> > > > Activity data in pages and this proposal outlines the changes needed
> > > > to the various OpenSocial specifications.
> > > > * Proposed changes
> > > > The to support Activitity Paging in the OpenSocial RESTful protocol,
> > > > RPC protocol and JavaScript are outlined below.
> > > > * RESTful protocol changes
> > > > No change is necessary. Section 6.5 of the v0.8.1 RESTful protocol
> > > > already specifies paging via startIndex and count for all collections
> > > > returned.
> > > > * RPC protocol changes
> > > > No change is necessary. Section 8.2 of the v0.8.1 RPC protocol already
> > > > specifies paging for activies via startIndex and count parameters.
> > > > * JavaScript API changes
> > > > Here, all we need to do is to provide a new static class
> > > > opensocial.DataRequest.ActivityRequestFields with he following fields:
> > > > <static> object FIRST
> > > > When paginating, the index of the first item to fetch;
> > > > specified as a number.
> > > > <static> object MAX
> > > > The maximum number of items to fetch, specified as a number;
> > > > defaults to 20.'
|
