OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Commented: (CAMP-42) Spec should say how to limit/specify the scope of returned data


    [ http://tools.oasis-open.org/issues/browse/CAMP-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32250#action_32250 ] 

Adrian Otto commented on CAMP-42:
---------------------------------

Although I think the query capability would be nice, I do tend to think that implementers should be free to use whatever approach they want.

Pagination, on the other hand, I don't see as a query feature, and can not be implemented efficiently or effectively on the client side alone. I think some pagination scheme should be offered, and CLIENTS should be required to support it. SERVERS will need to include previous and next links to show the position in the output. Responses will need to be ordered, and non-volatile to support the feature. This may require the server to hold state about a client requesting a paginated collection.

There is existing art to consider here:

http://docs.openstack.org/api/openstack-compute/2/content/Paginated_Collections-d1e664.html

Paginated Collections are needed in order to prevent API services from getting clogged. Please trust me, this is a major issue as the collections grow to be large. The implementer should be free to require that output from some or all services will always be represented as a paginated collection in the event that the result record count exceeds an upper threshold of records. For example, if more than 100 assembly instances would be returned by a query to an assembly template, that a paginated assembly is used, regardless if the client requested one. he spec should allow for such limits to be enforced by a service provider, and clients should be able to handle the abbreviated results.

> Spec should say how to limit/specify the scope of returned data
> ---------------------------------------------------------------
>
>                 Key: CAMP-42
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-42
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Task
>          Components: Spec
>            Reporter: Alex Heneveld
>            Assignee: Alex Heneveld
>
> Currently the spec only dictates requests whose response is an entire Resource object.  These Resources could be very large however, and it is wasteful for everyone to send the entire object if, as will commonly be the case I expect, the client is only interested in a small piece of the Resource.
> This spec should define how a client can restrict a query to selected items of the Resource.  This should include:
> * filtering: selecting a specific key or restricting to a set of keys
> * pagination: selecting a specific element or range of elements (where a key's value is of type list)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]