[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is this really an LCUP show stopper?
John McMeeking wrote:
My two bits worth:
I favor the LDAP Sync approach over LCUP. This is largely because changes
to LDAP Sync appear to make LCUP a valid implementation of LDAP Sync, and
it doesn't appear that LDAP sync would be significantly harder to
implement, from either the server or client perspective.
I think a very careful reading of the two drafts does expose some
important differences (and I admit I need to spend some more time
carefully reading draft-zeilenga-ldup-sync-02.txt). But I generally
agree that LDAP Sync includes much of what makes LCUP a good proposal.
As I understand it, this discussion basically boils down to how a client
finds out that an entry has left the result set and whether that imposes
undo requirements on an implementation or results in excessive network
traffic. The choices being:
1. Server sends "entry deleted" messages -- LCUP or LDAP Sync -- server
must maintain history
2. Server sends "entry present" messages for all entries in result set,
client determines what is gone -- LDAP Sync -- no history required
3. Reload required -- LCUP or LDAP Sync -- server doesn't have the
necessary history, or changes are "too big"
It seems to me that all these will all result in the client having the same
content, so I don't see an issue with either approach not working.
Agreed, for some value of "working." As the recent discussions have
shown, different approaches may work better in different situations
(most involve a tradeoff between implementation complexity and
performance or wire traffic).
I think the notion of maintaining a history so that a server can send
"entry deleted" messages is important. Synchronizing a 100,000 entry
directory with no (or limited) changes by sending 1000,000 entry present
messages seems like poor behavior. I believe that change to LDAP Sync was
It seems that LCUP could be implemented using LDAP Sync extended ops and
controls. A server implementation could always choose between options 1
and 3. And I think that would be a valid implementation of LDAP Sync. The
client, of course, would have to work properly with option 2, which might
make testing the client problematic if the client and server vendors are
the same. Similarly, a server implementation could choose to always use
options 2 and 3.
This is where we need to be careful. I am not convinced that option 2 is
a good idea, at least not for the kinds of applications I have in mind.
My guess -- and I admit this is only a guess -- is that the real
thinking behind the addition of the refreshDeletes option in
draft-zeilenga-ldup-sync-02.txt was to try to position LDAP Sync as a
superset of LCUP, with the hope being that those who support LCUP will
also support LDAP Sync. But I am not convinced we should shift
implementation complexity to the client, and increase the on the wire
traffic, by allowing server implementors to ignore the option 1 you
describe above. It will simply be too easy for them to provide a really
poor implementation of "a protocol that enables an LDAP client to
synchronize with the content of a directory information tree (DIT)
stored by an LDAP server and to be notified about the changes to that
content." And then the protocol will not be widely adopted by client
implementors, and then we will have solved no important problems.
I don't think that either LDAP Sync or LCUP will be significantly harder to
implement (either server or client side) if one accepts the notion that
some history is desirable. As stated earlier, I think that history is
necessary to a well-behaved synchronization mechanism.
Which is why I for one have no problem (and believe it may in fact be a
good idea) to encourage reasonable implementations to store some history.
I have not been able to come to any firm position on the need (or lack
thereof) for the "entry present" mechanism. It is clear that if the data
being synchronized is "large", and a change to entries and / or meta-data
results in a situation where the server knows that the content of entries
visible to the client has not changed, and a large number of entries has
potentially left the result set (without any equally large number of
entries entering the result set), that sending "entry present" results will
take less bandwidth than resending entire entries. It is far from clear to
me how likely such scenarios are. One case where the "entry present"
mechanism does work well is when a client synchronizes infrequently with
resect to the deleted/moved entry history maintained by the server.
I suspect either method will be sensitive to certain classes of changes
(most likely access control or group membership) that will result in some
clients being reloaded even though the net content change on the client is
small -- just too hard to figure out the delta.
Fair comments. It is certainly possible we are overthinking things in
this entire area. Implementation experience has already been fed back
into LCUP, and more of that will happen in the future.
Netscape Directory Product Development
My words are my own, not my employer's.