Is pagination optional?

[Kelly Grizzle]

I seem to remember some discussion around pagination being optional (maybe at the Cloud Identity Summit back in July?).  However, in reading the spec it is not explicitly noted as optional in section 3.2.2.3 and the ServiceProviderConfig resource does not have any attributes describing whether it is supported or not.  The pagination request parameters tables also states that when count is specified “the Service Provider MUST not return more results than specified”.  All of this points to pagination being required, I just wanted to double-check.

 

--Kelly

[Trey Drake]

Pagination is required.  Search (filter) is optional as not all implementors were able to support search.

Thanks,

Trey

[Mark Diodati]

Should pagination be optional? If not, SCIM service must support
pagination to be conformant. Are there use cases for simpler SCIM
services without pagination?

-Mark

On Mar 13, 11:13 am, Kelly Grizzle <kelly.griz...@sailpoint.com>
wrote:

[Kelly Grizzle]

In my opinion it should be required so that clients can behave nicely with large data sets. I had thought that one of the large vendors said that they didn't support pagination, but Trey reminded me that the concern was with filtering.

The paging that is mandated by the spec is offset-based, which should be fairly simple for servers to implement. Going forward I wouldn't mind seeing an token-based pagination added to the spec, but this should definitely be optional if it is added.

--Kelly

[Mark Diodati]

Makes sense.

Thanks,

Mark

On Mar 13, 10:38 am, Kelly Grizzle <kelly.griz...@sailpoint.com>

wrote:
> In my opinion it should be required so that clients can behave nicely with large data sets.  I had thought that one of the large vendors said that they didn't support pagination, but Trey reminded me that the concern was with filtering.
>
> The paging that is mandated by the spec is offset-based, which should be fairly simple for servers to implement.  Going forward I wouldn't mind seeing an token-based pagination added to the spec, but this should definitely be optional if it is added.
>
> --Kelly
>
>
>
> -----Original Message-----
> From: cloud-d...@googlegroups.com [mailto:cloud-d...@googlegroups.com] On Behalf Of Mark Diodati
> Sent: Tuesday, March 13, 2012 10:33 AM
> To: Cloud Directory
> Subject: Re: Is pagination optional?
>
> Should pagination be optional? If not, SCIM service must support pagination to be conformant. Are there use cases for simpler SCIM services without pagination?
>
> -Mark
>
> On Mar 13, 11:13 am, Kelly Grizzle <kelly.griz...@sailpoint.com>
> wrote:
> > I seem to remember some discussion around pagination being optional (maybe at the Cloud Identity Summit back in July?).  However, in reading the spec it is not explicitly noted as optional in section 3.2.2.3 and the ServiceProviderConfig resource does not have any attributes describing whether it is supported or not.  The pagination request parameters tables also states that when count is specified "the Service Provider MUST not return more results than specified".  All of this points to pagination being required, I just wanted to double-check.
>

> > --Kelly- Hide quoted text -
>
> - Show quoted text -

[c.nord...@gmail.com]

Hi,

I'm coming a little late to this but I am currently building a service provider and pagination is actually quite a hassle to implement the way the specification for 1.1 (and 2.0 from what I can tell) is written.

The problem lies with the index-based startIndex parameter.

I am working with a data source (specifically AWS DynamoDB, a cloud service, heh) that does not support index based queries and hence, as it stands, I can't be SCIM compliant because I can't use index-based pagination.

I would suggest making the startIndex a string to expand the ways you can use it.

To avoid having to deal with different implementations (index-based vs key based etc) on the client side, the service response must include a "nextIndex" property that can be passed as the startIndex in the consecutive pagination request. The initial request would omit the startIndex and only provide the count parameter thus indicating to the service provider that I want {count} resources starting from the first.

I think this would the index related problems with pagination and clients could still seamlessly switch between providers using different pagination schemes.

It could even be added to the existing spec without breaking any existing implementation by making nextMarker optional but saying that if it is provided clients should rely on it rather than calculating the next startIndex themselves as they currently would.

/ Carl