directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <>
Subject Re: [CONSTANTS] Changing AT and OC
Date Thu, 19 Apr 2007 16:39:37 GMT

On 4/19/07, Ole Ersoy <> wrote:
> Hey Alex,
> You do have auto complete you know :-)

This is not the problem.

The original idea here was to minimize the
> learning curve for future contributors and
> code reviewers.

Using AT and OC should not be a real problem. If you are down to the code
where you are using those abbreviations, then it means you already have a
certain level of knowledge about what is what in Ldap.

In that spirit I personally prefer to eliminate
> all abbreviations, with exceptions for
> special cases like where common terminology
> is used like DIT, or OU.

You personal preference are ok, but we are in a community, so we have to
accept this community habits and conventions. I don't think that all are ok,
and all don't fit my vision of what should be 'beautiful code', but at least
they are pretty close. You can still suggest something different, but
sometime people might disagree. However, this code base is now 3 years old
(and you can add 2 more years before it moved to apache), and we won't break
the commonly accepted conventions easily.

Also, the purpose of using constants is to
> ensure that the constant can be changed
> in one place only, and then be automatically
> updated in all other places.

Ole, we are aware of that. I think we all have a serious background in

> There are so many abbreviations in LDAP, like
> ou, cn, sn....that when more get added the cognitive
> load is pretty significant for beginners.

On the opposite, Ldap is not simple. RFCs which describe LDAp are huge :
probably around 500 pages if you gather all of them. Don't excpect LDAP to
be simple. The coginitive load *is* significant, even for experimented

> I think ApacheDS will be more popular for contributors
> when the code base is as simple as possible to work with.

The code base is *huge* (more than 260 KSLOC :, and more than 450 KLOC if you include
comments and blank lines). Don't expect new comers will have easy time
getting into it, it would be a lie to say that. However, I personally think
that the code base is pretty clean and neat, even if we do have some places
where it's not pure beauty...

Emmanuel L├ęcharny

View raw message