>
If you are suggesting that the order of objects returned from Locate should be made to be required to be deterministic then you should perhaps raise that as a separate proposal.
No. I am not suggesting this at all, as this would not solve the issue. Given the discussion at the last face to face I’m reluctant to raise much at all. I just wanted to point out, and you have confirmed, that
the proposed solution is not consistent with the specification, and that it is not robust to implementation differences (or in other words, it relies on server implementations being “sensible”, where sensible does not mean designed in accordance with the specification).
John
From:
[mailto:] On Behalf Of Tim Hudson
Sent: Friday, 16 May 2014 5:56 AM
To:
Subject: Re: [kmip] Groups - Locate with Offset uploaded
On 15/05/2014 8:58 PM, John Leiseboer wrote:
An observation: I assume that there is no guarantee or requirement for separate Locate requests to, even with identical match criteria, return the matched objects in the
same order.
There is no requirement on a KMIP server to return objects in any specified (or event consistent order) so a server is free to elect to be non-predicable if it so wishes. That has always been the case. Most sensible servers however do have a well defined order
mechanism in place (the mechanism does vary between vendors).
So a Locate require with a maximum items value repeated may return the same set of managed objects or a different set depending on the particular server vendors choice. New objects added between requests may appear or may not appear.
So then if, for example, there are say 100 objects on a server that match a Locate request, and if the client issues, say 10 sequential requests with offsets of 0, 10, 20,
etc. respectively, each with a maximum object count of 10, there is no guarantee that the client will actually be returned the full set of 100 objects. In fact, worst case, although probably unlikely, but possible, the client could see the same 10 objects
returned in each request.
If a server elects to implement with a non-consistent order in responses then this mechanism won't be much use for that type of server - although that type of server will have a pile of other issues entirely separate from supporting an
offset items value.
Does anyone disagree that this is possible given the current specification? Is this an issue for anyone?
The specification does not preclude a server vendor from implementing items in a manner that makes Locate responses less useful to a client then it should be. I recollect a discussion long ago on ordering of
responses from Locate but no requirement was added into the specification to mandate a particular order.
If you are suggesting that the order of objects returned from Locate should be made to be required to be deterministic then you should perhaps raise that as a separate proposal.
Tim.
