[occi-wg] JSON Rendering proposal, rev 2

Ralf Nyren ralf at nyren.net
Thu Mar 1 06:44:30 EST 2012


On Wed, 29 Feb 2012 14:36:16 -0700, Gary Mazz <garymazzaferro at 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.

>> 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
 
> 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".

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.

regards, Ralf



More information about the occi-wg mailing list