LDAP SDK and source repositories
Mark Banner
As most people will know, the majority of Mozilla development has moved
over to using Mercurial (aka hg) [1]. This includes the Thunderbird and
SeaMonkey repositories (comm-central [2] and mozilla-central).
One of the minor issues left is that we are still pulling the LDAP c-sdk
from a static tag in CVS into the Thunderbird & SeaMonkey builds that we do.
We'd like to move the source that we use in our builds from CVS to
Mercurial. For Thunderbird this would mean that we can drop the use of
CVS completely, for SeaMonkey, we wouldn't quite be able to, but we'd be
nearly there. This would also simplify our release processes and the
source control systems a user has to interact with.
There are several ways we can do this mainly depending on what the LDAP
SDK developers wish to do:
a) Move LDAP SDK development to Mercurial. Most of the implications for
this should be obvious. The directory/ code in cvs could be moved to its
own repository on hg.mozilla.org. Development would then continue in
hg.mozilla.org. Tagging and branching would be available if required.
There is also access control available should it be required.
The slight downside of this for comm-central is that comm-central would
have to decide what to do with its current directory/xpcom files as they
would want to exist in the same directory as the SDK files. We could
either add a sub-directory for the SDK or move the directory/xpcom back
alongside the SDK code.
b) Keep LDAP SDK development in CVS, snapshot LDAP SDK to Mercurial.
This would mean status-quo for the LDAP SDK developers.
For comm-central I would recommend going for the importing the source of
a specific tagged version directly into comm-central (as opposed to
creating a separate repository). The main reason for this is that
typically we only update the c-sdk a few times a year - therefore it
won't add much noise to the comm-central changesets.
This isn't urgent, but I would like to get agreement on the way forward
in the next few of weeks so that we know in which direction we are heading.
Standard8
[1] https://developer.mozilla.org/en/Mercurial
[2] https://developer.mozilla.org/en/comm-central
Robert Kaiser
> This isn't urgent, but I would like to get agreement on the way forward
> in the next few of weeks so that we know in which direction we are heading.
And just moving development of the c-sdk into comm-central isn't an
option? How much is it actually used outside of comm-central?
BTW, I had another user complaining about not being able to do libxul or
even XULRunner builds of our apps, and he said that some LDAP code was
where he saw breakage - if that was the c-sdk and not the xpcom stuff
then we might want to do a significant patch pass to enable this one time.
Robert Kaiser
Mark Banner
> Mark Banner wrote:
>> This isn't urgent, but I would like to get agreement on the way forward
>> in the next few of weeks so that we know in which direction we are
>> heading.
>
> And just moving development of the c-sdk into comm-central isn't an
> option? How much is it actually used outside of comm-central?
It isn't just the c-sdk: http://mxr.mozilla.org/mozilla/source/directory/
There is the java-sdk and a perl implementation as well, plus a few
other things.
These are released separately (from TB or SM) and I believe other
projects do use them.
It is a valid possibility, though historically (afaik because of the
separate releases) we've kept the SDKs separate so we can pull across
stable versions (just like mozilla-central does with NSS etc) and not
restrict/limit the SDKs to our development cycles, which I think would
happen if the SDKs were included directly in comm-central.
> BTW, I had another user complaining about not being able to do libxul or
> even XULRunner builds of our apps, and he said that some LDAP code was
> where he saw breakage - if that was the c-sdk and not the xpcom stuff
> then we might want to do a significant patch pass to enable this one time.
It would be the XPCOM code, and assuming I've not missed anything, there
is no point in doing a patch. To build with libxul you'd need to also
fix up autocomplete (including transitioning to toolkit) and finish the
transition of mailnews to the frozen api (there are bugs on all of
this). If you then wanted to do xulrunner, you'd also need to remove the
app and mailnews specific ifdefs that we have in core.
However this is part of the response is going off-topic, so if we want
to follow this up further we should do so under a different newsgroup/topic.
Standard8
Serge Gautherie
> This would also simplify our release processes and the
> source control systems a user has to interact with.
That's why I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=506601
(to be discussed here)
Lately, I started to look into some bugs involving the ldap c-sdk,
and managing cvs patches feels like a pain to me compared to hg (mq),
so I gave up.
> a) Move LDAP SDK development to Mercurial.
>
> The slight downside of this for comm-central is that comm-central would
> have to decide what to do with its current directory/xpcom files
Another downside is that c-c (and other projects) would have to pull the
whole ldap repo, instead of just the (c-)sdk directory it needs.
Fwiw, a (Mercurial 1.3, "experimental") solution could be
http://mercurial.selenic.com/wiki/NestedRepositories
http://mercurial.selenic.com/wiki/subrepos
The ldap developers could pull the main (+ nested) repo(s) (if they need
one),
projects could pull the sdk they need only :-)
> b) Keep LDAP SDK development in CVS, snapshot LDAP SDK to Mercurial.
> This would mean status-quo for the LDAP SDK developers.
Yes, the basic "need" of c-c would be a c-sdk only hg (mirror) repo.
(Could be the true c-sdk repo (see above), or a mirror repo managed by
either the directory team or the mailnews one if need be...)
> For comm-central I would recommend going for the importing the source of
> a specific tagged version directly into comm-central
That would be the simpliest way.
Yet, I'm not sure I like it:
*No more 'client.py --skip-ldap', though I guess it's rarely used.
*Probably no history between the imported versions.
*Newer checkins not imported so much harder to use the import to
contribute to c-sdk.
I think managing a separate (c-sdk only) (mirror) repo would not be
really harder and have more uses than importing into c-c.
Rich Megginson
> Mark Banner wrote:
>> This isn't urgent, but I would like to get agreement on the way forward
>> in the next few of weeks so that we know in which direction we are
>> heading.
>
> And just moving development of the c-sdk into comm-central isn't an
> option? How much is it actually used outside of comm-central?
The c-sdk, perl-sdk, and java-sdk are part of the Red Hat Enterprise
Linux and Fedora linux distributions and are used by many applications
in those distributions. They are also used by many Sun/Solaris products.
Rich Megginson
Moving to Mercurial is fine with me. I've been using git now for quite
some time and have really grown to like how much better it is than CVS.
I understand hg is similar to git. As far as the repo layout, it
doesn't matter to me if the c-sdk has its own top level repo or is part
of a larger repo, as long as it is easy to
1) checkout just the c-sdk
2) build just the c-sdk
3) tag individual and separate c-sdk releases
4) produce individual source code releases of the c-sdk
Robert Kaiser
> It would be the XPCOM code
Ah, OK, good to know.
> To build with libxul you'd need to also
> fix up autocomplete (including transitioning to toolkit) and finish the
> transition of mailnews to the frozen api (there are bugs on all of
> this).
IIRC, all that is planned for the future, right?
> However this is part of the response is going off-topic, so if we want
> to follow this up further we should do so under a different
> newsgroup/topic.
True, just wanted to assess what the impact of that libxul-targeted work
in on the LDAP c-sdk.
Robert Kaiser
Robert Kaiser
> a) Move LDAP SDK development to Mercurial. Most of the implications for
> this should be obvious. The directory/ code in cvs could be moved to its
> own repository on hg.mozilla.org. Development would then continue in
> hg.mozilla.org. Tagging and branching would be available if required.
> There is also access control available should it be required.
Would it make sense to have a "ldap" directory on hg.mozilla.org and
make the different SDKs be different repos, actually?
Robert Kaiser
Serge Gautherie
> Moving to Mercurial is fine with me. I've been using git now for quite
:-)
> some time and have really grown to like how much better it is than CVS.
> I understand hg is similar to git. As far as the repo layout, it
Yes, afaik.
> doesn't matter to me if the c-sdk has its own top level repo or is part
> of a larger repo, as long as it is easy to
> 1) checkout just the c-sdk
> 2) build just the c-sdk
> 3) tag individual and separate c-sdk releases
> 4) produce individual source code releases of the c-sdk
Then you do want a separate c-sdk repo.
(And you can use the repoNestedRepositories/subrepos feature on top of
it, if need be: see my previous message.)
Then it should be much like what was done for DOMi and Venkman:
import with (some) history.
Time to confirm the filed bug?
Mark Banner
> Mark Banner wrote:
>> a) Move LDAP SDK development to Mercurial.
>>
>> The slight downside of this for comm-central is that comm-central
>> would have to decide what to do with its current directory/xpcom files
>
> Another downside is that c-c (and other projects) would have to pull the
> whole ldap repo, instead of just the (c-)sdk directory it needs.
The "whole ldap repo" is actually quite small relatively speaking, I
don't think that would be an issue.
> Fwiw, a (Mercurial 1.3, "experimental") solution could be
> http://mercurial.selenic.com/wiki/NestedRepositories
> http://mercurial.selenic.com/wiki/subrepos
> The ldap developers could pull the main (+ nested) repo(s) (if they need
> one),
> projects could pull the sdk they need only :-)
Yes, that is EXPERIMENTAL. Looking at the list of details there are
quite a few known issues there at the moment.
>> For comm-central I would recommend going for the importing the source
>> of a specific tagged version directly into comm-central
>
> That would be the simpliest way.
>
> Yet, I'm not sure I like it:
> *No more 'client.py --skip-ldap', though I guess it's rarely used.
--skip-ldap only stops you getting the source. It doesn't control
building which if anything is the more important option.
> *Probably no history between the imported versions.
Nope, but that isn't a major issue IMHO because the main repo would have
that if you're really looking for a bug.
> *Newer checkins not imported so much harder to use the import to
> contribute to c-sdk.
We have that issue at the moment. I don't see c-c devs doing major
development on the c-sdk at the moment so I don't think that is a real
barrier.
> I think managing a separate (c-sdk only) (mirror) repo would not be
> really harder and have more uses than importing into c-c.
I just don't see a major developmental need for it.
Standard8
Mark Banner
> Moving to Mercurial is fine with me. I've been using git now for quite
> some time and have really grown to like how much better it is than CVS.
> I understand hg is similar to git. As far as the repo layout, it doesn't
> matter to me if the c-sdk has its own top level repo or is part of a
> larger repo, as long as it is easy to
> 1) checkout just the c-sdk
hg clone http://hg.mozilla.org/whatever/it/is
> 2) build just the c-sdk
As normal ;-)
> 3) tag individual and separate c-sdk releases
hg tag -r <changeset> MY_TAG
I'm not quite sure what you mean by separate c-sdk releases.
> 4) produce individual source code releases of the c-sdk
You can:
hg clone ....
hg update -r MY_TAG
Then you could zip it up, which would include the history, or I expect
we could probably copy one of the source tar ball commands from the
mozilla-central/comm-central build systems that would get you just the
source files.
Rich, so are you saying you would be happy to split the different SDKs
across repositories? Or would you prefer them all in one?
The only thing I can think of with having them all-in-one is that one
tag would tag all the files in the repository, but I guess that isn't
really an issue.
From a comm-central view point I think we could cope with either,
although if we did an all-in-one I'd probably think about moving the
xpcom sdk back to the LDAP repository as that would also help building
binary extensions against xulrunner with LDAP.
Mark.
Mark Banner
> Rich Megginson wrote:
>> doesn't matter to me if the c-sdk has its own top level repo or is
>> part of a larger repo, as long as it is easy to
>> 1) checkout just the c-sdk
>> 2) build just the c-sdk
>> 3) tag individual and separate c-sdk releases
>> 4) produce individual source code releases of the c-sdk
>
> Then you do want a separate c-sdk repo.
No, he's saying it doesn't matter.
> Then it should be much like what was done for DOMi and Venkman:
> import with (some) history.
> Time to confirm the filed bug?
No. Please be patient - like I said this is a non-urgent issue. I'd
especially like to give Mark, Anton and Dan time to respond as well.
Standard8
Serge Gautherie
> On 27/07/2009 17:25, Rich Megginson wrote:
>
>> 1) checkout just the c-sdk
>
> hg clone http://hg.mozilla.org/whatever/it/is
Ftr, (afaict,)
'whatever/it' is the (optional) path under which the 'is' repository lives.
'clone' clones a (full) repository: that's why I wrote that a separate
('c-sdk' only) repository was wanted.
>> 3) tag individual and separate c-sdk releases
>
> hg tag -r <changeset> MY_TAG
Likewise, 'tag' tags a revision, which means it applies to the whole
repo. (branch).
>> 4) produce individual source code releases of the c-sdk
>
> You can:
>
> hg clone ....
>
> hg update -r MY_TAG
>
> Then you could zip it up, which would include the history, or I expect
> we could probably copy one of the source tar ball commands from the
> mozilla-central/comm-central build systems that would get you just the
> source files.
While I understand zipping the source files in the c-sdk dir of a
working copy,
I don't quite follow your steps :-(
> The only thing I can think of with having them all-in-one is that one
> tag would tag all the files in the repository, but I guess that isn't
> really an issue.
(see above)
> From a comm-central view point I think we could cope with either,
> although if we did an all-in-one I'd probably think about moving the
> xpcom sdk back to the LDAP repository as that would also help building
> binary extensions against xulrunner with LDAP.
I don't know much about the xpcom sdk,
but, in the "one repo per sdk", this sdk could just move to its own repo
too...
Rich Megginson
> On 27/07/2009 17:25, Rich Megginson wrote:
>> Moving to Mercurial is fine with me. I've been using git now for quite
>> some time and have really grown to like how much better it is than CVS.
>> I understand hg is similar to git. As far as the repo layout, it doesn't
>> matter to me if the c-sdk has its own top level repo or is part of a
>> larger repo, as long as it is easy to
>> 1) checkout just the c-sdk
>
> hg clone http://hg.mozilla.org/whatever/it/is
Ok, good.
>
>> 2) build just the c-sdk
>
> As normal ;-)
heh
>
>> 3) tag individual and separate c-sdk releases
>
> hg tag -r <changeset> MY_TAG
Would this tag the entire repo, or just the c-sdk portion? Or does it
really matter? I know with git, tags are cheap and easy to manage, so
it doesn't really matter.
>
> I'm not quite sure what you mean by separate c-sdk releases.
If it doesn't matter that non-c-sdk code will be tagged with a c-sdk
release tag, then it doesn't matter if the c-sdk repo is completely
separate.
>
>> 4) produce individual source code releases of the c-sdk
>
> You can:
>
> hg clone ....
>
> hg update -r MY_TAG
>
> Then you could zip it up, which would include the history, or I expect
> we could probably copy one of the source tar ball commands from the
> mozilla-central/comm-central build systems that would get you just the
> source files.
With git, I can use the git archive command to produce a source tarball
from a specific tag or changeset (commit). But I think that archives
the entire repository, not a subdirectory. If that's not possible, then
we can just use clone and update to get the local source repo in the
right state, then just use tar directly against the source repo.
>
>
> Rich, so are you saying you would be happy to split the different SDKs
> across repositories? Or would you prefer them all in one?
For the perl and java sdks, they can be separate, since (afaik) no other
mozilla component uses them. For the c-sdk, as long as we can preserve
the ability to develop and make c-sdk releases independent of
t-bird/seamonkey, if it makes life easier for t-bird/seamonkey
developers to have the code embedded in their larger source code
repositories, I think that would be fine.
>
> The only thing I can think of with having them all-in-one is that one
> tag would tag all the files in the repository, but I guess that isn't
> really an issue.
As long as tags are cheap and easy to manage, which I'm assuming they
are with hg.
Serge Gautherie
> On 28/07/2009 06:49, Serge Gautherie wrote:
>> Rich Megginson wrote:
>>> doesn't matter to me if the c-sdk has its own top level repo or is
>>> part of a larger repo, as long as it is easy to
>>> 1) checkout just the c-sdk
>>
>> Then you do want a separate c-sdk repo.
>
> No, he's saying it doesn't matter.
Yes, that's what he said,
but how do you achieve '1' if the c-sdk dir is in a larger hg repo?
>> Time to confirm the filed bug?
>
> No. Please be patient - like I said this is a non-urgent issue. I'd
> especially like to give Mark, Anton and Dan time to respond as well.
Sure, I just thought we had had a (positive) answer and solution much
sooner than expected :-|
Mark Smith
>> From a comm-central view point I think we could cope with either,
>> although if we did an all-in-one I'd probably think about moving the
>> xpcom sdk back to the LDAP repository as that would also help building
>> binary extensions against xulrunner with LDAP.
>
> I don't know much about the xpcom sdk,
> but, in the "one repo per sdk", this sdk could just move to its own repo
> too...
First, let me say that on the LDAP side of things, Rich and Anton's
opinions are much more important than mine (I no longer work with LDAP
on a day-to-day basis).
Given the relatively small size of all of the LDAP code, I don't see a
big advantage in the "one repository per SDK" solution. It seems like
less overhead and simpler to me to have one repository for all of the
LDAP SDKs. There may be a technical (hg) or philosophical reason to
have separate repos that I am not aware of though.
Also, I am not in favor of a solution that will cause two copies of the
code to be maintained (or stored) in two different places. When we did
that in the past, the C SDK code used by Thunderbird just kept getting
older and older and changes were made in two places... and the result
was a small mess. Pulling from the same repository but using a tag to
provide stability to consumers like TBird and SeaMonkey is my
preference. I assume that is what is still done for NSS and NSPR?
--
Mark Smith
Pearl Crescent
http://pearlcrescent.com/
Serge Gautherie
> Mark Banner wrote:
>> On 27/07/2009 17:25, Rich Megginson wrote:
> Would this tag the entire repo, or just the c-sdk portion? Or does it
> really matter? I know with git, tags are cheap and easy to manage, so
> it doesn't really matter.
Entire repo, but tagging is cheap/easy with hg too.
> If it doesn't matter that non-c-sdk code will be tagged with a c-sdk
> release tag, then it doesn't matter if the c-sdk repo is completely
> separate.
Though it doesn't matter, I would find this odd:
probably acceptable with c-sdk in a directory repo,
but unexpected in the comm-central repo.
> With git, I can use the git archive command to produce a source tarball
> from a specific tag or changeset (commit). But I think that archives
Same:
hg archive [OPTION]... DEST
create an unversioned archive of a repository revision
> the entire repository, not a subdirectory. If that's not possible, then
Maybe
-I --include include names matching the given patterns
-X --exclude exclude names matching the given patterns
would help?
> we can just use clone and update to get the local source repo in the
> right state, then just use tar directly against the source repo.
(Yes: again, the bigger the repo is the odder it feels.)
> For the perl and java sdks, they can be separate, since (afaik) no other
> mozilla component uses them. For the c-sdk, as long as we can preserve
> the ability to develop and make c-sdk releases independent of
> t-bird/seamonkey, if it makes life easier for t-bird/seamonkey
> developers to have the code embedded in their larger source code
> repositories, I think that would be fine.
Personally, I would think the 'c-sdk in comm-central', either as the
main repo or as just an import, was only a workaround solution in case
you would have wanted to continue with cvs. Then not relevent anymore.
But maybe others think differently.
Serge Gautherie
> Given the relatively small size of all of the LDAP code, I don't see a
> big advantage in the "one repository per SDK" solution. It seems like
> less overhead and simpler to me to have one repository for all of the
> LDAP SDKs. There may be a technical (hg) or philosophical reason to
> have separate repos that I am not aware of though.
(for me)
The main reason is technical: to be able to handle the c-sdk separately.
But, if that doesn't matter (anymore), I assume a directory repo with
all the sdks would be fine.
> Also, I am not in favor of a solution that will cause two copies of the
> code to be maintained (or stored) in two different places.
I concurr.
> Pulling from the same repository but using a tag to
> provide stability to consumers like TBird and SeaMonkey is my
> preference. I assume that is what is still done for NSS and NSPR?
Yes, and for cvs c-sdk too ;-)
Mark Banner
>> Pulling from the same repository but using a tag to provide stability
>> to consumers like TBird and SeaMonkey is my preference. I assume that
>> is what is still done for NSS and NSPR?
>
> Yes, and for cvs c-sdk too ;-)
No it isn't done for NSS and NSPR. They are still developed in cvs and
when they are upgraded the source gets merged into mozilla-central on hg
- which version is just tracked by the tags in cvs.
mozilla-central builds have everything included in hg, they didn't want
to go the multiple repository way because of the one or two extra steps
it would cause them to do - so they do duplicate the code (but the rule
is no-one checks into the nss/nspr directories apart for when upgrading).
Standard8
Serge Gautherie
Right, I mixed things up! :-(
NSPR & NSS: imported from tagged cvs into m-c repo (and m-1.9.1).
ldap c-sdk: pulled directly from tagged cvs into c-c working dir.
Robert Kaiser
> 1) checkout just the c-sdk
You can only checkout a complete repo at a time, so you'd need to e.g.
clone the whole ldap-sdks repository and will have the c-sdk in a
directory beneath it, but you'll never get the c-sdk alone unless it is
its own repo.
Robert Kaiser
Rich Megginson
Ok. This should not be a big deal, just makes life easier for
developers (although a developer would typically just clone the repo
once or once per platform) and release engineering (would be nice to be
able to produce a c-sdk source tarball without checking out lots of
other unrelated code).
>
> Robert Kaiser
Rich Megginson
That's essentially the way it is now in CVS:
directory/
c-sdk/
java-sdk/
perldap/
>
> Robert Kaiser
Dan Mosedale
Since perldap and java-sdk both depend on the c-sdk, if the perl/java
build infrastructure depends on having the c-sdk in a
guaranteed-to-exist known location, it might need to be tweaked a bit if
the three are in separate repos. From the point of view of consuming
applications that want to pull from the repo(s) directly, it strikes me
that most such apps are going to care at most about one language
binding, so the ability to pull & tag that on its own seems like a win
there. As other folks have pointed out, there isn't really that much
code, so it's not that big of a deal either way.
Dan
Rich Megginson
Note that perldap does depend on and requires the c-sdk at build time
and at run time. perldap does not need to be built "in tree' - you can
built it with a separate standalone c-sdk installation (and nspr and nss
too). The java-sdk is completely independent - it has no dependency on
the c-sdk at all.
>
> Dan
Rich Megginson
Note that perldap does depend on and requires the c-sdk at build time
Serge Gautherie
> I'd especially like to give Mark, Anton and Dan time to respond as well.
Afaict, the discussion so far seems to have an agreement that:
*one repo is possible as the whole code is light ;-)
*multiple repos are finer-grained and acceptable to manage :-)
Are we looking/waiting for Anton's input?
Anton Bobrov
folks, i'm sorry for delay answering this. from where i stand here is
what makes most sense to me [ quote from somewhere on this thread
earlier ] :
"to have a "ldap" directory on hg.mozilla.org and make the
different SDKs be different repos"
i'm against the idea of mixing them all up although i can see how it
can make sense from higher level perspective. i'm also against
maintaining and syncing multiple copies from multiple repositories.
other than that i'm pretty much ok with whatever is deemed best for
the rest of the Mozilla dev community in this case.
Serge Gautherie
> "to have a "ldap" directory on hg.mozilla.org and make the
> different SDKs be different repos"
For example, we could have a "ldap-central" directory (like
http://hg.mozilla.org/l10n-central),
which would contain the actual sdk hg repositories.
A layout much like http://mxr.mozilla.org/mozilla/source/directory/.
> i'm against the idea of mixing them all up although i can see how it
> can make sense from higher level perspective.
In other words, you're in favor of "having one repo per sdk"?!
> i'm also against
> maintaining and syncing multiple copies from multiple repositories.
In other words, you're in favor of "keeping the ldap c-sdk as an
external resource of comm-central, as it is now: not copying releases
in-tree"?!
> other than that i'm pretty much ok with whatever is deemed best for
> the rest of the Mozilla dev community in this case.
Good :-)
Now, who is responsible to make the actual decision?
Xu, Qiang (FXSGSC)
Which one is the original LDAP C SDK, MozLDAP or OpenLDAP?
Why MozLDAP is poorly maintained, while OpenLDAP is actively maintained?
Thanks,
Xu Qiang
> -----Original Message-----
> From:
> dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.mozilla.org
>
> [mailto:dev-tech-ldap-bounces+qiang.xu=fujixe...@lists.moz
> illa.org] On Behalf Of Serge Gautherie
> Sent: Wednesday, August 19, 2009 10:31 AM
> To: dev-te...@lists.mozilla.org
> Cc: Anton....@Sun.COM
> Subject: Re: LDAP SDK and source repositories
> _______________________________________________
> dev-tech-ldap mailing list
> dev-te...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-ldap
>
Anton Bobrov
Serge Gautherie wrote:
> which would contain the actual sdk hg repositories.
> A layout much like http://mxr.mozilla.org/mozilla/source/directory/.
that sounds good.
> In other words, you're in favor of "having one repo per sdk"?!
i dont wanna end up in a situation when people check out C-SDK
for example they also get PERL-SDK and JAVA-SDK with it.
> In other words, you're in favor of "keeping the ldap c-sdk as an
> external resource of comm-central, as it is now: not copying releases
> in-tree"?!
yes.
Mark Smith
> Just an off-topic question:
>
> Which one is the original LDAP C SDK, MozLDAP or OpenLDAP?
>
> Why MozLDAP is poorly maintained, while OpenLDAP is actively maintained?
As with nearly all open source projects, the reason is community
involvement. Most people do not have time to learn about and contribute
to more than one LDAP project, so in my opinion it was inevitable that
one would become more popular than the other. OpenLDAP also ships with
most (nearly all) Linux distributions.
Both LDAP implementations have their roots in the original LDAP
implementation that was developed at the University of Michigan in the
early to mid 1990s.
--
Mark Smith
Pearl Crescent, LLC