[occi-wg] Preliminary JSON rendering draft, discussion material

[Ralf Nyren]

On Thu, 19 Jan 2012 12:58:55 +0000, <florian.feldhaus at tu-dortmund.de>
wrote:

> The OpenStack approach looks interesting. If understand it correctly,
then
> they use the "marker" to specify the ID of an element. The IDs are whole
> numbers and not UUIDs like in OCCI. Thus it may be a problem to directly
> map it to OCCI as UUIDs are not incremental. I would suggest, that we
use
> the approach suggested by Ralf, but maybe expect the server to sort the
> entities by create time in descending order, as is specified for
OpenStack.

Will have a look at the OpenStack approach.
 
> How do we proceed with the document? Is it available somewhere? Can I
edit
> it? How do we coordinate finnishing the JSON rendering? Is the
> json_rendering.tex in the OCCI SVN (see [1]) the latest version? Should
I
> / we update that document?

The latest version should be in OCCI SVN. We can update it together if you
like but
please follow the "Directives for using LaTeX with version control
systems" [1].

Most importantly do not introduce unnecessary line breaks such as
re-indenting
paragraphs (*poke* Thijs ;).

That and commit'ing chunks of smaller increments will make merging so much
easier.

Also need to find a suitable way to formally specify the JSON structures.
Using
ABNF which includes JSON syntax may become be unnecessarily complex.

regards, Ralf

[1]
http://en.wikibooks.org/wiki/LaTeX/Collaborative_Writing_of_LaTeX_Documents


> Cheers,
> Florian
> 
> [1] 
>
https://forge.ogf.org/integration/viewcvs/viewcvs.cgi/trunk/json_rendering.
> tex?root=occi-wg&rev=491&system=exsy1001&view=log
> 
> Am 19.01.12 12:46 schrieb "Edmonds, AndrewX" unter
> <andrewx.edmonds at intel.com>:
> 
>>I completely agree with Ralf on the need for pagination. It's also worth
>>looking at OpenStack's approach to pagination [1] as we have the
>>semantics and syntax in the OCCI model to support this.
>>
>>Andy
>>
>>[1] 
>>http://docs.openstack.org/api/openstack-compute/1.1/content/Paginated_Coll
>>ections-d1e664.html
>>
>>-----Original Message-----
>>From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On Behalf
>>Of Ralf Nyren
>>Sent: Thursday, January 19, 2012 11:16 AM
>>To: florian.feldhaus at tu-dortmund.de
>>Cc: occi-wg at ogf.org
>>Subject: Re: [occi-wg] Preliminary JSON rendering draft, discussion
>>material
>>
>>
>>Nice summary Florian! Just one comment on the pagination issue, see
below.
>>
>>On Thu, 19 Jan 2012 10:53:04 +0000, <florian.feldhaus at tu-dortmund.de>
>>wrote:
>>>>The pagination of GET requests may also prove to be problematic, as
>>>>resources may be deleted between successive GET requests. As mentioned
>>>>above, I would prefer to have the OCCI server return ALL
>>>>OCCI-Locations for a GET request and then let the client do additional
>>>>GET requests for each resource.
>>> 
>>> We couldn't touch this subject properly in the call. From my point of
>>> view, paginating requests is not a good idea, as we break the
>>non-stateful
>>> REST concept. We might consider the HTTP header field range to achieve
>>> this behaviour. In general, I would prefer not to have pagination due
>>> to the problem that it may be possible to add or remove entities from
>>> the list between two consecutive requests with pagination.
>>
>>I still believe we need pagination, client needs a way to avoid getting
>>drowned in large collection responses.
>>
>>Pagination is not a problem if the server does not guarantee that "page
2"
>>is based on the exact same collection as "page 1".
>>
>>We simply say that in requesting collection items 10-20 you get those
>>item based on the collection at the time of the request.
>>
>>Example:
>> - Client request items 1-10
>> - A new item is added as "number 2" in the collection (based on the
>>sorting rules chosen by the server implementation)
>> - Client requests items 11-20. The client will see item "10" again but
>>as number 11 in the list this time.
>>
>>This should be easy enough to implement on the server side and this kind
>>of pagination is better than none at all.
>>
>>What do you think?
>>
>>/Ralf
>>_______________________________________________
>>occi-wg mailing list
>>occi-wg at ogf.org
>>https://www.ogf.org/mailman/listinfo/occi-wg
>>-------------------------------------------------------------
>>Intel Ireland Limited (Branch)
>>Collinstown Industrial Park, Leixlip, County Kildare, Ireland
>>Registered Number: E902934
>>
>>This e-mail and any attachments may contain confidential material for
>>the sole use of the intended recipient(s). Any review or distribution
>>by others is strictly prohibited. If you are not the intended
>>recipient, please contact the sender and delete all copies.
>>