[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [kmip] Groups - Locate with Offset uploaded
>
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 relies on consistent ordering in the Locate, AND it only “works” when uncontrollable external factors (that would influence the set of objects found by a Locate request) do not arrive at the server during the sequence of Locate requests.
The first condition is not a requirement of the standard. The second condition is well outside the scope of the standard. Can this proposal be relied upon by clients to deliver objects without duplication, or omission? No. Can constraints on server implementation (like ordered Locate results) fix the proposal? No. The proposal is fundamentally flawed. Given the possibility of duplicated and omitted objects, should this proposal be accepted? That’s the question I am asking. Note that the probability of duplicated and omitted objects will reach 100% under conditions that
can be very easily induced by authenticated, authorised users of the system operating in full conformance with the KMIP specification. >
Mandating ordering of Locate responses would be a separate item. Red herring. Consistent ordering is not why the proposal is broken, and will not fix it. It is the stateless nature of the KMIP protocol. >
Mandating stateful multi-request responses would be a separate item. Red herring. Stateful multi-request responses are not required. >
But you are revisiting the whole topic of the offset+limit approach to Locate… Given that this proposal is all about the topic of offset+limit approach to Locate, by definition any discussion is revisiting the
topic. By your logic, nobody should review or discuss this proposal, lest they be accused of revisiting the topic. What I was not revisiting is the specific topic that I raised with respect to message flow control. Granted, what I raised at the face to face
would have solved the problem, and indeed many others. But this is of course, yet another red herring. The topic we’re discussing is the current proposal. We’re not discussing alternate proposals. Indeed, as a group, the decision may to be to accept this flawed
proposal, not bother with offset+limit for Locate at all, or to solicit alternate proposals. That’s to be decided. And if this is revisiting the topic, then I am guilty, and I make absolutely no apologies for it. > 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?
Red herring. Consistent ordering is not why the proposal is broken, and will not fix it. It is the stateless nature of the KMIP protocol. >
Does this preclude a server vendor from implementing this as a server-side preserved SQL transaction state against the client request?
Red herring. Server implementation is not the issue. This is a protocol issue that needs to be addressed at protocol level. >
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. Red herring. Consistent ordering is not why the proposal is broken, and will not fix it. It is the stateless nature of the KMIP protocol. >
If there is consensus that there should be a consistent order for items returned in Locate… Red herring. Consistent ordering is not why the proposal is broken, and will not fix it. It is the stateless nature of the KMIP protocol. John From: kmip@lists.oasis-open.org
[mailto:kmip@lists.oasis-open.org] On Behalf Of Tim Hudson On 16/05/2014 6:28 AM, John Leiseboer wrote:
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.
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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]