Re: [kmip] Groups - Locate with Offset uploaded

[Tim Hudson <tjh@cryptsoft.com>]

On 16/05/2014 9:18 AM, John Leiseboer wrote:

> Right now we have a simple proposal that solves enough of a known problem. It doesn't attempt to do everything.

Right now we have a simple proposal that does not solve the problem at all. It cannot be relied upon. It is not consistent with the KMIP protocol.

It is - in that it solves the problem it is trying to solve - and doesn't solve the separate problem you are raising. Others have already indicated that solving that problem is of interest (most vendors have this capability in their servers already long before KMIP came along). That you don't see it as useful yourself is entirely up to you.

KMIP is (mostly) stateless and so actions that impact the lists returned in Locate can occur between requests. You may get repeated items, you may get missed items. This is precisely how the design pattern from SQL for offset and limit works - correctly applied - where the transaction scope between separate invocations is handled separately -  i.e. where there isn't a transaction scope (stateful) required between requests. SQL allows for transaction state handling entirely separate from the offset and limit and even for user selectable levels of transaction consistency including running without transaction consistency at all.

This is exactly the same context when you can perform the same Locate operation between two requests - it can return different answers. That it can doesn't mean that KMIP is broken or the sky is about to fall in - it is simply the choice of the technical committee. Pointing out that because there isn't a guaranteed transaction consistency cross-requests doesn't make that capability not fit for purpose.

You can also perform a Locate then immediately follow up with a Get and have the Get fail because someone else has performed a Destroy - again that is a reflection of the choices within the protocol itself. It doesn't mean Locate is broken. It doesn't mean KMIP is broken. It does mean that a user of KMIP should be aware of this. But we don't include warnings in the documentation about that for each Operation noting that things may have changed from the previous request - we have error codes which provide for reporting that.

This proposal isn't for a stateful iterator guaranteed to return all objects within a KMIP server across multiple requests (which seems to be what you are asking for) - its a paging mechanism over a (mostly) stateless Locate operation. It has exactly the same properties you would get if you used limit+offset within SQL statements in separate transactions.

If you want to be able to perform a series of separate requests with generic stateful transaction handling between them then you can always raise that item again - but so far there has been no other support for that approach - and such a change would require broad support within the technical committee.

Tim.