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?
No.
Does it implement a well known and well understood design pattern
that is widely used?
Yes.
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.
Tim.
