[oslc-core] Pagination

[Frank Budinsky]

> You now
> reject this design because it doesn't support fetching an individual
> entry

I was actually rejecting it because it DOES support fetching an individual
entry (i.e., a server will return 200 OK for GET <ChangeLog>#fragment). but
it's possible/likely that the requested resource isn't in the result. So
the client is lead to believe the request was successful, but the result is
missing. For this reason, I think using OSLC paging (in general) to
paginate resources that contain fragment IDs is a bug. Do you agree, or do
you think it would be acceptable to just document that GET
<ChangeLog>#fragment is not supported and should not be called (because the
result is unreliable)?

> but then you propose instead a different design that doesn't
> support that feature either.

I was assuming that we could still optionally support addressable "change
entries" (as opposed to addressable "list entries"), as described in the
current version of the proposal document:

<https://.../ChangeLog>
  oslc:changes (<https://.../changeEvent/103> <https://.../changeEvent/102>
<https://.../changeEvent/101>) .

I don't think there's any harm in allowing this, but to be perfectly
honest, I haven't yet seen a use case for it. The only justification I've
seen is that it's best to say that client's need to be able to support
this, even if it's not used by any servers right away, so that they have
the option to do it in the future without breaking clients.

> Your new
> design disappoints is a different way - the resource that said it
> was the changelog actually isn't - it's only the first "segment" of
> the changeLog. That can be easily fixed by avoiding claiming it's a
> full changelog in the first place, perhaps like this:
>
> <https://.../ChangeLog?oslc:firstSegement>
>   oslc-log:changes (
>     ...
>     ]) ;
>   oslc-log:continuation <https://.../ChangeLog?pageno=2> .

I wonder if it would be even better to not use query strings at all, but
instead just give each segment a unique URI.

<https://.../ChangeLog>
   oslc-log:changes (
     ...
     ]) ;
   oslc-log:continuation <https://.../ChangeLog_1> .

This way, the http://.../ChangeLog can claim to be the ChangeLog, just like
the first entry of a list can claim to be the list. The ChangeLog is
essentially the first entry of a linked list of ChangeLog segments, each
containing a page worth of entries.

Frank.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20110323/917073e4/attachment-0003.html>