[Date Prev][Date Next]
Re: backglue transition
Aaron Richton wrote:
re:1 - I just consider the notion of "glue-sub" from 2.3.0-2.3.6 a
mistake and would like to pretend we just used the 2.1-2.2 syntax
continuously. Since I think the number of people adopting 2.3 at this
early stage is probably small, I figured this move would solve more
problems than it caused.
So a few things bother me:
1. The slapo-glue config that worked yesterday with 2.3.6 doesn't work--at
all--today with 2.3.7.
2. The config that we tried to be compatible with from, say, 2.2.28
doesn't work the same way with 2.3.7.
3. If I try to use either of those old configs, I get no
warnings/errors/etc. despite the fact there's a behavior change.
Finally, although I realize there were reasons for moving things into core
and making 'subordinate' the keyword, I really liked the slapo-glue
syntax. In my ideal world, the new backglue would be able to handle either
style of config. I don't know if the new design makes this
re:2 - I must've gotten confused as to which behavior I was trying to
preserve. We can certainly swap it back to be identical to the 2.2
order; this should be filed as an ITS. Basically I had no compelling
reason for it to be one way or the other...
re:3 you'll get some kind of diagnostic message, but only if you have a
non-zero debug level or loglevel.
I actually preferred the glue-sub syntax as well because of the more
explicit associations of subordinate and superior DBs. But it also
invited misunderstanding (e.g. Hallvard's example with multiple glue
overlays configured in a single DIT) which would never have come up
using the old subordinate syntax. As such, while it would have been
feasible to keep it, I felt that it was more harm than good.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/