[occi-wg] JSON Rendering proposal, rev 2

[Gary Mazz]

On 2/29/2012 11:07 AM, Ralf Nyren wrote:
> On Wed, 29 Feb 2012 18:32:18 +0100, Gary Mazz 
> <garymazzaferro at gmail.com> wrote:
>
>> Based on the traditional nature of the http client/server protocol, 
>> saying the media type is json should be sufficient. If at some time 
>> in the future, request queuing on a connection is supported, 
>> depending on method implemented it should be revisited.
>
> Not convinced. Let's say I want to write a nice litte firefox plugin 
> which can render OCCI JSON formats nicely. If the media-type does not 
> tell that the content is OCCI-json and not some arbitrary json, such a 
> plugin would be hard to get working.
>
> The JSON rendering is exposed over HTTP. Any HTTP client is able to 
> issue valid requests. If the payload returned is marked as 
> "occi-stuff" it is much easier to have support in a wider range of 
> clients.
>
> Whether to have just application/occi+json or multiple media-types for 
> json is a different topic though.

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.

>
>>> What to call the category identifier? I used "rel" now based on the 
>>> HTTP way of doing things. Any better naming suggestions, "type" ? [1]
>>
>> A little perspective on 'rel'. This is an artifact based on the HTML5 
>> and RDFa rendering that haven't yet matured.  I would suggest we keep 
>> the 'rel' in case the there is a huge shift to semantic  approaches 
>> for cloud computing.
>
> Sure, keep "rel" then. Other thoughts, someone?
>
>>> I guess we could put the "next" link in a Link header and actually 
>>> use RFC5988 as it was meant to be used (as opposed to how we abused 
>>> it in text/occi rendering). We have to verify if browsers would 
>>> choke on this though and it makes life a bit harder for JavaScript 
>>> implementations which would need to parse the Link headers. Other 
>>> ideas?
>>>
>> This is a query capability and should not be part of any portion of 
>> the format or http protocol.
>
> 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...

This is the confusion. The link to the next page is a "query" and not 
part of the occi data. It is important but for other reasons. In the 
http rendering, it was required to place it where it was, there was not 
other capability available. Now that there was time to think about the 
approach in more detail and take advantage of json's additional 
capabilities, we may want to reconsider the approach.

We have 2 issues with the current query mechanism, query context and 
data consistency.  We originally perused "links to the next page" as 
part of the HTML5 rendering. I was in support of the idea at the time 
because it made web client development easier. Since that time, the 
industry has changed and browsers are smarter and better techniques 
including MVC have entered the space.  The occi http specification 
retained some of the html5 artifacts.

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.

>> I think there is some confusion about document structure and 
>> presentation with the occi model. Granted, this has been clearly 
>> vetted withing the group.  We should keep this discussion in terms of 
>> a query. The "marker" as suggested is essentially acting as an 
>> arbitrary index or iteration context in application.  We should be 
>> clear on the use cases and whether the "marker/iterator'  applies to 
>> occi entities, json entities and payload size. There are very 
>> separate concerns that seem to be getting integrated as some levels.
>
> The marker applies to resource instances (Entity sub-type instances ;) 
> but on a HTTP protocol level. Makes sense?

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

>
> /Ralf
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/occi-wg