Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: Core
    • Labels:
      None
    • Proposal:
      Hide

      Acknowledging that there is value to requesting a specific page size, I recommend the following verbiage:

      When responding to a request that includes oslc.pageSize, a server SHOULD return a representation that contains the requested number of values in its response. If the server deems that the response size is too large, the server MAY return a smaller number of values than the requested number in its response. Finally, a server may ignore the oslc.pageSize request completely.

      This is still not fully handled (what happens if the server wants to return a larger set of values, or if pageSize is negative? How to handle discoverability of server's preferences?) but it's at least somewhat better.

      Show
      Acknowledging that there is value to requesting a specific page size, I recommend the following verbiage: When responding to a request that includes oslc.pageSize, a server SHOULD return a representation that contains the requested number of values in its response. If the server deems that the response size is too large, the server MAY return a smaller number of values than the requested number in its response. Finally, a server may ignore the oslc.pageSize request completely. This is still not fully handled (what happens if the server wants to return a larger set of values, or if pageSize is negative? How to handle discoverability of server's preferences?) but it's at least somewhat better.

      Description

      Currently the core spec says "OSLC Services may ignore oslc.pageSize."

      What this probably means is it could respond with the requested number of values, or it could respond with no paging at all, or it could respond with a different number of values than what was requested. Which means, there really aren't any constraints on the server when the client makes this request, in which case we may as well drop this request option entirely since it duplicates the functionality of oslc.paging=true. Assuming we want to get value from oslc.pageSize, we should probably differentiate between servers that can do paging and simply choose to not do so, or servers that can't support paging at all. Not sure what to do about that but some guidance on discoverability may be in order.

        Attachments

          Activity

            People

            • Assignee:
              jamsden James Amsden
              Reporter:
              sarabura Martin Sarabura [X] (Inactive)
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: