[occi-wg] JSON Rendering proposal, rev 2

[alexander.papaspyrou at tu-dortmund.de]

Am 29.02.2012 um 19:07 schrieb Ralf Nyren:

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

I see your point. I guess then we should have application/occi+<something>, and then really stay with that.

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

Well, I think queries should be handled via URL parameters. But I thought we were talking about pagination interlinking.

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

If you would use it in the context of RFC5988, then yes.

-A.

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

-- 
Alexander Papaspyrou
alexander.papaspyrou at tu-dortmund.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alexander Papaspyrou.vcf
Type: text/directory
Size: 498 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20120301/9a1e4bbd/attachment-0002.bin>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4678 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20120301/9a1e4bbd/attachment-0003.bin>