[occi-wg] JSON Rendering proposal, rev 2

[Gary Mazz]

On 3/1/2012 4:44 AM, Ralf Nyren wrote:
> 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.

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
>