Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando Should SID/RID be decimal (0-999) as in parsing and the rest of the syncrepl code, or hexadecimal (0-FFF) as in code generating CSN values? I understand the point is (almost) moot, but we'd get there as soon as someone starts using >10-way multimaster... I'm fixing the code so that it consistently uses hex server IDs, please holler if using decimals is preferred. p.
moved from Incoming to Software Bugs
changed notes
ando@sys-net.it wrote: > Should SID/RID be decimal (0-999) as in parsing and the rest of the syncrepl > code, or hexadecimal (0-FFF) as in code generating CSN values? I understand the > point is (almost) moot, but we'd get there as soon as someone starts using >> 10-way multimaster... or, if RID is to be typed in decimal form, let's remove the 3 digit limitation, and set a < 4096 limitation like for serverID. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
changed notes changed state Open to Test
ando@sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re23 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > Submitted by: ando > > > Should SID/RID be decimal (0-999) as in parsing and the rest of the syncrepl > code, or hexadecimal (0-FFF) as in code generating CSN values? I understand the > point is (almost) moot, but we'd get there as soon as someone starts using >> 10-way multimaster... > > I'm fixing the code so that it consistently uses hex server IDs, please holler > if using decimals is preferred. The SID in the CSN has always been hex (but usually zero). The RID is not part of the CSN and has always been decimal. Since the RID only needs to be unique within a particular slapd instance, there's no real problem there. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Howard Chu wrote: > ando@sys-net.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD/re23 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.63.140.131) >> Submitted by: ando >> >> >> Should SID/RID be decimal (0-999) as in parsing and the rest of the >> syncrepl >> code, or hexadecimal (0-FFF) as in code generating CSN values? I >> understand the >> point is (almost) moot, but we'd get there as soon as someone starts >> using >>> 10-way multimaster... >> >> I'm fixing the code so that it consistently uses hex server IDs, >> please holler >> if using decimals is preferred. > > The SID in the CSN has always been hex (but usually zero). The RID is > not part of the CSN and has always been decimal. Since the RID only > needs to be unique within a particular slapd instance, there's no real > problem there. > Right. but, well, slap_parse_csn_sid() was using strtoul(..., 10). Now fixed. For consistency I've made both behave the same. The user won't basically notice it, so I don't see backward compatibility issues. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
ando@sys-net.it wrote: > Howard Chu wrote: >> The SID in the CSN has always been hex (but usually zero). The RID is >> not part of the CSN and has always been decimal. Since the RID only >> needs to be unique within a particular slapd instance, there's no real >> problem there. >> > > Right. but, well, slap_parse_csn_sid() was using strtoul(..., 10). Now > fixed. Yeah, oops. That's good. > For consistency I've made both behave the same. The user won't > basically notice it, so I don't see backward compatibility issues. So we leave the docs saying RID is 0-999? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Howard Chu wrote: > ando@sys-net.it wrote: >> Howard Chu wrote: > >>> The SID in the CSN has always been hex (but usually zero). The RID is >>> not part of the CSN and has always been decimal. Since the RID only >>> needs to be unique within a particular slapd instance, there's no real >>> problem there. >>> >> >> Right. but, well, slap_parse_csn_sid() was using strtoul(..., 10). Now >> fixed. > > Yeah, oops. That's good. > >> For consistency I've made both behave the same. The user won't >> basically notice it, so I don't see backward compatibility issues. > > So we leave the docs saying RID is 0-999? Well, in slapd.conf(5) I already put 0-4095, but be can back it out. I don't have any preference. Since the max will just slightly increase, I don't see a big deal in terms of backwards compatibility. In any case 4096 or 1000 is big for a RID, so no-one will be hurt. I was more concerned about the 10 limit... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
ando@sys-net.it wrote: > Well, in slapd.conf(5) I already put 0-4095, but be can back it out. I > don't have any preference. Since the max will just slightly increase, I > don't see a big deal in terms of backwards compatibility. In any case > 4096 or 1000 is big for a RID, so no-one will be hurt. I was more > concerned about the 10 limit... OK. I kind of think they ought to be documented differently, so that people don't confuse SIDs with RIDs (as often happened in OpenLDAP 2.2) but it's probably fine the way it is. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes moved from Software Bugs to Development
changed notes changed state Test to Release
changed notes changed state Release to Closed
moved from Development to Archive.Development
syncrepl fixed in HEAD/RE24