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 <[email protected]> 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/ >
