You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2009/01/09 22:55:22 UTC
CSN, ADS and OpenLDAP
Hi,
currently, for replication, we are using a CSN built from
http://tools.ietf.org/html/draft-sermersheim-ldap-csn-02 (more or less).
In fact, our CSN is a composition of a timestamp
(System.currentMillis()), an operation operationSequence and a
replicaId. It is constructed this way :
timestamp:replicaId:operationSequence (no padding)
It's not what OpenLDAP is using. OpenLDAP is based on
http://tools.ietf.org/html/draft-ietf-ldup-model-09, and a CSN is
constructed this way :
" ...
* The format of a CSN string is: yyyymmddhhmmssz#s#r#c
* where s is a counter of operations within a timeslice, r is
* the replica id (normally zero), and c is a counter of
* modifications within this operation. s, r, and c are
* represented in hex and zero padded to lengths of 6, 3, and
* 6, respectively. (In previous implementations r was only 2 digits.)
...
"
So far, both CSN are incompatible. We could write translators, but I
also think that it would be great to avoid having a different structure.
Does it makes sense to you ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: CSN, ADS and OpenLDAP
Posted by Alex Karasulu <ak...@gmail.com>.
Having the same CSN structure will eventually facilitate compatibility with
OpenLDAP and also the -09 version is much newer than the -02 so why not.
Alex
On Fri, Jan 9, 2009 at 5:06 PM, Howard Chu <hy...@symas.com> wrote:
> Emmanuel Lecharny wrote:
>
>> Hi,
>>
>> currently, for replication, we are using a CSN built from
>> http://tools.ietf.org/html/draft-sermersheim-ldap-csn-02 (more or less).
>> In fact, our CSN is a composition of a timestamp
>> (System.currentMillis()), an operation operationSequence and a
>> replicaId. It is constructed this way :
>>
>> timestamp:replicaId:operationSequence (no padding)
>>
>>
>> It's not what OpenLDAP is using. OpenLDAP is based on
>> http://tools.ietf.org/html/draft-ietf-ldup-model-09, and a CSN is
>> constructed this way :
>>
>> " ...
>> * The format of a CSN string is: yyyymmddhhmmssz#s#r#c
>> * where s is a counter of operations within a timeslice, r is
>> * the replica id (normally zero), and c is a counter of
>> * modifications within this operation. s, r, and c are
>> * represented in hex and zero padded to lengths of 6, 3, and
>> * 6, respectively. (In previous implementations r was only 2 digits.)
>> ...
>> "
>>
>> So far, both CSN are incompatible. We could write translators, but I
>> also think that it would be great to avoid having a different structure.
>>
>> Does it makes sense to you ?
>>
>> Hm, I was co-authoring an update of Jim Sermersheim's draft, to
> standardize on the OpenLDAP format. We never published it, I guess that may
> be my fault. But I expect that the OpenLDAP format is the one that will
> progress to the IETF, so obviously I recommend sticking with that.
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
Re: CSN, ADS and OpenLDAP
Posted by Howard Chu <hy...@symas.com>.
Emmanuel Lecharny wrote:
> Hi,
>
> currently, for replication, we are using a CSN built from
> http://tools.ietf.org/html/draft-sermersheim-ldap-csn-02 (more or less).
> In fact, our CSN is a composition of a timestamp
> (System.currentMillis()), an operation operationSequence and a
> replicaId. It is constructed this way :
>
> timestamp:replicaId:operationSequence (no padding)
>
>
> It's not what OpenLDAP is using. OpenLDAP is based on
> http://tools.ietf.org/html/draft-ietf-ldup-model-09, and a CSN is
> constructed this way :
>
> " ...
> * The format of a CSN string is: yyyymmddhhmmssz#s#r#c
> * where s is a counter of operations within a timeslice, r is
> * the replica id (normally zero), and c is a counter of
> * modifications within this operation. s, r, and c are
> * represented in hex and zero padded to lengths of 6, 3, and
> * 6, respectively. (In previous implementations r was only 2 digits.)
> ...
> "
>
> So far, both CSN are incompatible. We could write translators, but I
> also think that it would be great to avoid having a different structure.
>
> Does it makes sense to you ?
>
Hm, I was co-authoring an update of Jim Sermersheim's draft, to standardize on
the OpenLDAP format. We never published it, I guess that may be my fault. But
I expect that the OpenLDAP format is the one that will progress to the IETF,
so obviously I recommend sticking with that.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/