[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: entryUUID

At 01:33 AM 6/16/2005, Howard Chu wrote:
>Kurt D. Zeilenga wrote:
>> At 09:59 AM 6/14/2005, Pierangelo Masarati wrote:
>>> I want to use syncrepl to easily build a "master" consumer out of
>>> third party DSAs that don't support all stuff required by syncrepl,
>
>> Hmmm....  not sure exactly what your trying to do.
>
>> I'd like slapd(8) to be slave off of anything.  If LDAPsync is not
>> available on the provider, I'd like syncrepl to use whatever is, even
>> if that means using basic LDAP operations.
>
>> When syncrepl uses say basic LDAP operations, saying a timestamp
>> based approach, then one can create entryUUIDs and entryCSNs as
>> needed.  The former can be arbitrary (if this slave maintains a copy,
>> or create_from_name otherwise (maybe with DN+createTimestamp)). The
>> latter can be produced from the timestamp (which, depending how one
>> designs the mechanism, should be enough).
>
>Given the way syncrepl works now, I think we should back away from the CSN requirement in our implementation and only use timestamps.

We can certainly use internally either a CSN or a timestamp
which has sufficient resolution such that no two changes ever
have the same stamp, but we'll always have the issue that
the party were LDAPsync'ing with uses the other, or something
else.  So, we need to support conversion as well, or something
standard.

I choose CSN because, at the time, timestamps in most implementations
didn't have the resolution necessary, and there was some effort
to standardize CSNs.  Today, well, timestamps with many implementations
still don't have the resolution necessary, and efforts to standardize
CSNs are, though not completely stalled, certainly not moving quickly.

>If we assume the use of timestamps with fractional seconds, so that stamp resolution is always fine enough to distinguish between individual operations, then there's nothing useful to us in the other fields of the CSN anyway.

Yes, CSN has always been overkill.  The issue with timestamp has always
been that some implementations (including some clients) don't do well
with fractional seconds.

>Ultimately our use of CSNs has only served to make OpenLDAP release 2.2 and newer more incompatible with 2.1 and older, and other vendors, with no appreciable benefit in exchange.

Well, my view was that the introduction of LDAPsync was not going
to be compatible with older releases.  However, LDAPsync aside,
it would have been nice to support (slurpd) replication between
minor releases.  But slurpd makes that hard to do.  With LDAPsync,
the consumer is in control, so it should not be easier to make
future releases more easily support being consumers of current
releases, and vice versa.


>-- 
> -- Howard Chu
> Chief Architect, Symas Corp.       Director, Highland Sun
> http://www.symas.com               http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support