On 3/1/2012 4:44 AM, Ralf Nyren wrote:
On Wed, 29 Feb 2012 14:36:16 -0700, Gary Mazz<garymazzaferro@gmail.com> wrote:
Well, I think the root of this discussion is whether the client knows he is talking to occi or not. We already know the json specification does not include the capability to presenting occi information in a webpage. This is important for the context of the discussion. So, what other types of 'generic' applications are going to be talking to occi ? Web browser, probably not. SEO robots ? maybe.. Other applications that know about occi, definitely. We need to consider applying the client's context in defining the capabilities. OCCI is an application specific interface with a narrow functional scope. It does not 'need', based on today's client/server operation, capabilities as if it were serving generic web pages. If the specification included html5 and widgets, I would be prone to agree with your position. However, unless there is a need in the future to expand the capabilities, the current approach on this subject seems unnecessary and adds additional complication to client implementations. Just to make clear, this argument is whether to use application/json or application/occi+json. Not about using multiple media-types as in my latest proposal.
Yes, agreed that most occi clients will be aware that they talk to an OCCI server and not some other json capable service.
However, I don't see what the complications would be of having application/occi+json. You say this may be relevant in the future so why not get it right from the beginning, the penalty seems very low to me.
A valid use case for OCCI Json rendering on the browser side is an AJAX client as a generic management interface for arbitrary OCCI services. However, you could of course argue this is an application aware of talking to an OCCI server. Additionally you actually avoid some potential security problems by not using "applcation/json". E.g. silly javascript eval() whenever json content is found.
I was just working through the use cases to evaluate the impact of 'application/json' and 'application/occi+json'. It seems, at least from a simple rationalization, that the client would know it talking to an occi server. In that case, it probably doesn't matter which media type is presented. The second use case, is someone using a browser to access the occi/json site. In that case, its probably a developer or technically skilled person and they would also know they are accessing an occi server. Again, it probably doesn't matter which media type is presented. The last use case is a robot, ie seo scanner. They do request media types as 'application/json'. The question is do we want to refuse those requests via media types ?
Where to put it then? The whole point of the "marker" concept is to return a link to the next "page" in the response. That link has to go somewhere... An argument against links to the next page is that the link/iterator is a state resulting from a query maintained in the server. Since the client has already requested a range, the client should maintain the position as part of the query context passed in the query request. Otherwise, the protocol between the client an server is no longer stateless. Additionally, if the client is already maintaining the query context, placing a query context in the server is only redundant. Good point, thanks for taking time to explain. We simply leave it up to the client to maintain state on which "page" it has requested last. Protocol-wise paging only exist on the query level then.
I would like to leave the "total collection size" value in the data format though. That way a server still has the option to throttle the response size when necessary.
Something like this then?
"Get 50-entries page _after_ resource xxx": GET /compute/?marker=xxx&start=1&end=51
"Get 50-entries page _before_ resource xxx": GET /compute/?marker=xxx&start=-1&end=-51
"Get 10 resources _including_ resource xxx": GET / compute/?marker=xxx&start=0&end=10
Yes, this will work nicely :)
New comment:
Multi-user administration consoles and automated has introduced new complexities. Configurations and states can change after a page has been transferred to the client. Data consistency of both the consumer and provider occi data may change after the consumer has queried.
It could be unreasonable for the provider to maintain to event information in occi's context. If the notification is tied to a query and the life cycle of the query is tied to the connection, the provider can discard the query and notification when the connection is closed. There need to be either a notification or a time tag assigned to a query to detect changes on state. Yes, the currently proposed pagination would produce inconsistent results if the collection is modified between requests. The thought was to accept this as a limitation and say "a provider SHOULD by default sort a
collection based on resource creation time".
The issue is 'creation time', which seems like a good idea. But, there is more than creation to be concerned with..
Adding support for server side "collection pagination state" as you suggest would be nice from a client perspective but the question is if the added complexity on the server side is really worth it.
From a purely interface perspective, I would also challenge the value of the approach. However, from a client usability perspective, I can't see not having some push event indicating changes. The alternative forces the client to continuously poll the server. Multi-access provider interfaces require a way for clients to keep occi information consistent across the multiple occi clients. This use case becomes increasing important for brokers. This type of query is an interesting case for occi's approach to interface. A notification query is a long running occi operation. Currently, states of long running operations associated with occi objects are maintained with the occi object. This feature allows the interface to remain stateless which greatly simplifies client and server implementations. In the past, long running occi operations has been consciously avoided, outside of some recommendations. We probably are running into a time where 'long running operations' and push indicators are revisited. cheers, gary
regards, Ralf