RE: LDAP Client Update: consideration of alternative proposals

At 07:55 PM 6/3/2003, Ed Reed wrote:
>Irony is having someone else argue for state-based synchronization
>approaches after going so long with LDUP in which no one was
>interested in them.

Maybe its just those who have implemented state-based
synchronization are not interested in LDUP...

>As I recall, some of us thought the implementation choice of the
>backend didn't matter to the consumers of the protocol, until
>we ran into all the various ordering constraints necessary
>to deal with partial transfers of changes (necessary in 
>the absence of commit/rollback semantics, if you want to
>avoid retransmission of already sent changes).

I recall it being resolved that log-based implementations
had like problems dealing with partial replication.  Anyways,
I think the conclusion of that particular thread was that
LDUP should not get into log-based nor state-based implementation
details.

>I'm glad I'm not the one trying to justify them, this time.

I rather not have to justify any particular implementation
approach and just leave those to the implementors.  LCUP,
unlike LDUP, precludes viable implementation approaches.


>>>> "Kurt D. Zeilenga" <[email protected]> 6/3/2003 6:15:00 PM >>>
>
>At 08:37 AM 5/29/2003, Chris Apple wrote:
>>Perhaps one source of difficulty in discussions
>>related to this topic is that there is not
>>agreement between yourself and the editors
>>of LCUP as to how broad a range of applicability
>>is appropriate for the LCUP deliverable?
>
>It's my opinion that LCUP deliverable should be generally
>applicable to directory applications needing content
>synchronization facilities.  Both drafts seem to have the
>same applicability in terms of directory applications they
>apply to, how they differ significantly in the kinds of
>constraints they place on their implementations.
>
>I use the term constraint here instead of requirement to
>highlight the distinction of fulfilling a need of the
>directory applications versus of fulfilling a need of the
>design of a protocol.
>
>Our basic application requirement is that protocol provide
>efficient and effective content synchronization, with modes
>for polling for changes and listing for changes.  Efficient
>implies a need to manage protocol exchanges to minimize
>traffic in most cases while generally avoiding "overly"
>chatty behavior.  Effective implies a need for a reasonable
>level of data consistency.
>
>Applications could care less of whether their requirement
>was met using a history based approach or using state
>indicators based approach, that's an server implementation
>detail to them.   Hence, draft-ietf-ldup-lcup need for
>servers to maintain and use history information is not an
>application requirement but a design constraint.
>
>I consider the draft-ietf-ldup-lcup's history design
>constraint unreasonable.  This constraint certainly will
>will have an impact on its wide adoption as a technical
>solution to the general problem.
>
>Kurt