On 2/29/2012 11:07 AM, Ralf Nyren wrote:
On Wed, 29 Feb 2012 18:32:18 +0100, Gary Mazz <garymazzaferro@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@ogf.org https://www.ogf.org/mailman/listinfo/occi-wg