Moving to Mercurial - Proposals for the LDAP code and its effect on autoconfig (MCD)
Mark Banner
This post includes several sections:
- Background
- Proposal
- Effects
- Comments
== Background ==
As many will already know, following the core Mozilla codebase move to
Mercurial, SeaMonkey and Thunderbird are also planning on moving to
Mercurial soon (http://wiki.mozilla.org/MailNews:HgMeetingNotes), this
will be in a new comm-central repository.
One issue that needs resolving is the location of the LDAP code. There
are two many parts that are used, currently located (in cvs) as follows:
mozilla/directory/c-sdk - the main c-sdk for LDAP
mozilla/directory/xpcom - xpcom wrapper around the c-sdk
There are also other mozilla/directory/* directories and files relating
to the LDAP sdk.
== Proposal ==
The current proposal is:
1) Leave mozilla/directory/c-sdk (and related directories) development
in cvs (until such a time it is wished to move it).
2) We can then either: Import snapshots into the Mercurial repository
similar to NSS/NSPR or obtain a version via cvs and an appropriate
static tag.
3) Move development of mozilla/directory/xpcom to Mercurial located in
the new comm-central repository (the old code would remain in cvs just
to allow continuning support on the 1.9.0 builds).
4) Remove the capability from core to build the LDAP code (both c-sdk
and xpcom).
== Effects ==
- The autoconfig code in extensions/pref/autoconfig will no longer be
able to support LDAP (I think across any app).
- Firefox and xulrunner will not be able to include LDAP functionality
(this is a currently not included by default, only as a compile time
option - and I'm belive it doesn't work on xulrunner).
- Development of the c-sdk can remain in cvs and move to a separate
Mercurial repository if/when the developers wish to do so.
- Development of the xpcom wrapper will be the responsibility of
Thunderbird/SeaMonkey, which I believe it has been for quite a while now.
== Comments ==
See
http://developer.mozilla.org/en/docs/MCD,_Mission_Control_Desktop_AKA_AutoConfig
for more info on what autoconfig does.
The proposal would mean that Firefox/xulrunner would loose the
capability to be compiled with LDAP functionality for autoconfig.
Currently SeaMonkey and Thunderbird would also loose the LDAP
functionality for autoconfig. I have only taken a brief look at the
code, and from that I expect we may be able to rewrite the ldap module
of autoconfig so that it could be built from within the new comm-central
repository and overlaid into the core code.
Comments welcome, expect this to happen as soon as we are ready to
transfer into the new repository, we haven't got a timescale yet, but I
would expect in the next couple of weeks.
Standard8
Mark Banner
newsgroup names]
Dan Mosedale
> [Follow-ups set to mozilla.dev.planning]
>
> == Effects ==
>
> The proposal would mean that Firefox/xulrunner would loose the
> capability to be compiled with LDAP functionality for autoconfig.
It would be really nice to get some understanding of who is currently
depending on that functionality. mkaply, do you have any feel for this?
> Currently SeaMonkey and Thunderbird would also loose the LDAP
> functionality for autoconfig. I have only taken a brief look at the
> code, and from that I expect we may be able to rewrite the ldap module
> of autoconfig so that it could be built from within the new comm-central
> repository and overlaid into the core code.
Given that extensions/pref/autoconfig is in mozilla-central, why is
re-writing likely to be necessary? Since XPCOM doesn't require any
actual link-time dependency, wouldn't adding a few hooks to the
mozilla-central buildsystem to look elsewhere for LDAP headers be
enough? If so, this would provide an avenue for interested Firefox
builders to spend bandwidth on keeping the Firefox functionality alive
as well.
Dan
Howard Chu
> [Follow-ups set to mozilla.dev.planning][Repost due to incorrect
> newsgroup names]
>
> This post includes several sections:
>
> - Background
> - Proposal
> - Effects
> - Comments
>
> == Background ==
>
> As many will already know, following the core Mozilla codebase move to
> Mercurial, SeaMonkey and Thunderbird are also planning on moving to
> Mercurial soon (http://wiki.mozilla.org/MailNews:HgMeetingNotes), this
> will be in a new comm-central repository.
I hadn't been paying attention to these developments before, but see that now...
> - The autoconfig code in extensions/pref/autoconfig will no longer be
> able to support LDAP (I think across any app).
>
> - Firefox and xulrunner will not be able to include LDAP functionality
> (this is a currently not included by default, only as a compile time
> option - and I'm belive it doesn't work on xulrunner).
So this seems like no loss at the moment. I didn't even think there was
anything in Firefox that used LDAP. What would, if it had been enabled?
> - Development of the c-sdk can remain in cvs and move to a separate
> Mercurial repository if/when the developers wish to do so.
>
> - Development of the xpcom wrapper will be the responsibility of
> Thunderbird/SeaMonkey, which I believe it has been for quite a while now.
>
> == Comments ==
>
> See
> http://developer.mozilla.org/en/docs/MCD,_Mission_Control_Desktop_AKA_AutoConfig
> for more info on what autoconfig does.
> Currently SeaMonkey and Thunderbird would also loose the LDAP
> functionality for autoconfig. I have only taken a brief look at the
> code, and from that I expect we may be able to rewrite the ldap module
> of autoconfig so that it could be built from within the new comm-central
> repository and overlaid into the core code.
Since I've been working on OpenLDAP compatibility here anyway
https://bugzilla.mozilla.org/show_bug.cgi?id=292127
I'd be willing to investigate whatever new work the autoconf module needs,
particularly since I was going to need to hack on it anyway to enable
selecting OpenLDAP here.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Mike Shaver
> So this seems like no loss at the moment. I didn't even think there was
> anything in Firefox that used LDAP. What would, if it had been enabled?
LDAP-based preference/profile autoconfig, I believe.
Mike
Rich Megginson
> [Follow-ups set to mozilla.dev.planning][Repost due to incorrect
> newsgroup names]
>
> This post includes several sections:
>
> - Background
> - Proposal
> - Effects
> - Comments
>
> == Background ==
>
> As many will already know, following the core Mozilla codebase move to
> Mercurial, SeaMonkey and Thunderbird are also planning on moving to
> Mercurial soon (http://wiki.mozilla.org/MailNews:HgMeetingNotes), this
> will be in a new comm-central repository.
>
mozilla/security/svrcore)?
> One issue that needs resolving is the location of the LDAP code. There
> are two many parts that are used, currently located (in cvs) as follows:
>
> mozilla/directory/c-sdk - the main c-sdk for LDAP
> mozilla/directory/xpcom - xpcom wrapper around the c-sdk
>
> There are also other mozilla/directory/* directories and files relating
> to the LDAP sdk.
>
instead of hg, but hg is a fine distributed SCM. There is plenty of hg
support on the linux platforms that Red Hat uses, and the MozillaBuild
package for Windows includes hg. Do you know if there are pre-built
binaries of hg available for HP-UX and Solaris (if there are already
Mozilla developers working on those platforms). If not, no big deal,
it's just a nice to have.
> Standard8
> _______________________________________________
> dev-tech-ldap mailing list
> dev-te...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-ldap
>
>
>
timeless
> I would like to just move everything to hg.
> Do you know if there are pre-built binaries of hg available for HP-UX
> and Solaris (if there are already Mozilla developers working on those
> platforms).
OpenSolaris development *transitioned* to Hg.
4. Freeware for Solaris
This is the Mercurial Source Control Management (SCM) system. ......
Today, I needed to build a toolset on a Solaris 9 machine (without a
C/C++ compiler). ...
www.sunfreeware.com/indexsparc9.html -
so Mercurial's available for Solaris 9 from sunfreeware, and would
presumably be available for 10 which is the supported shipping version
and of course Open which is presumably "next".