OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [kmip] Groups - Locate with Offset uploaded

On 16/05/2014 6:28 AM, John Leiseboer wrote:

> This proposal is entirely consistent with the specification

The proposal does not address the lack of ordering. The proposal does not address stateless server design.

Nor was it intended to address those issues. Mandating ordering of Locate responses would be a separate item. Mandating stateful multi-request responses would be a separate item. This proposal does neither of those.

> If you want to revisit that issue…

NO! I DO NOT WANT TO REVISIT THAT ISSUE. Is that clear to you?

But you are revisiting the whole topic of the offset+limit approach to Locate which was discussed at the face to face and we had a consensus to proceed down that path with a simple proposal and there was no support for taking the different approach you roughly outlined in the face to face meeting. You withdrew from moving forward on that item given the lack of support from others within the TC and indicated you accepted the consensus of the group at the time and simply disagreed with it. I think that is a fair and accurate reflection on that discussion.

In between two Locate operations another client (or the server admin) could add or remove multiple objects from the list which matches the Locate parameters. This isn't suggesting or requiring that the server provide a single consistent transaction across multiple requests - that isn't what it is about - this is about providing the typical paging mechanism in independent requests which is what is normally handled.

Most server vendors already have this sort of mechanism in place with well understood semantics. That you are looking for effectively a guaranteed cross-request transaction state with what you raised previously at the face to face which is aimed at a different problem domain.

Does this proposal do everything?

Does it implement a well known and well understood design pattern that is widely used?

Do I think server vendors who haven't implemented a consistent order in Locate responses have made the wrong choice?
Yes. But the specification allows for that choice to be made as it does in a whole pile of areas. It tends to make the server responses a lot less useful for dealing with any lists of managed objects (entirely independent of this proposal). I would suspect that server vendors with such a design approach would find less success in the market - but as a technical committee we don't mandate a particular server internal design approach and we have kept a lot of things clearly open to different design approaches.

Does this preclude a server vendor from implementing this as a server-side preserved SQL transaction state against the client request?
No. Nor does it require it. That is left up to the server vendor as a design choice.

Now if we wanted to add some more Query functions to return items like whether or not the Locate response has a well defined order for a given implementation I can add that as a separate proposal.

If there is consensus that there should be a consistent order for items returned in Locate then I can add that as a separate proposal.

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]