Open Bug 36557 Opened 24 years ago Updated 3 months ago

[Meta] LDAP Support

Categories

(MailNews Core :: Address Book, enhancement)

Product:
MailNews Core
Component:
Address Book
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: metrol, Unassigned)

References

(Depends on 5 open bugs)

Details

(Keywords: helpwanted, meta, Whiteboard: nab-ldap) 

It has recently come to my attention that Mozilla will not be integrating LDAP
support into the address book interface.  After a bit of discussion on the
Usenet to comfirm what I had heard I decided to present my arguments with
Bugzilla to you developers working on this.

I am responsible for all the hardware and software decision at my company, which
is made up of about 100 users.  A long while ago I ran through testing every
mail client I could download to compare them feature for feature.  At the end of
my testing I decided to go with NS 4.x due to the way it handled addresses with
auto fill, and how I could integrate my mail server's LDAP support into this.

From that decision, all the users at my company are now using NS 4.x as their
primary E-Mail client, and have been doing so now for over a year.  I've stuck
through problems like it's inability to deal with multiple accounts, lack of
filing features, and a slew of other annoyances mostly due to seemless handling
of LDAP into the auto fill on the address field.  This has made it simple for me
to both train new users, and to quickly deploy our company address book to both
internal and remote users.

If I go to deploy the final release of Netscape 6.0 to my end users without LDAP
support the scene is going to look like the end of 'Frankenstein' where the
villagers are coming to the gates of the castle with pitch forks and torches in
hand.  I've got a company full of folks that have come to rely upon this feature
that I have implemented.

Thing of it is, I know I can't be the only admin out here that utilizes LDAP as
a way of distributing a company address book.  Every major mail server out there
supports this, to include Netscape's.  Mozilla will be telling all of us
corporate users that our needs are just not as important as feeding stock
reports through RDF on the side bar.

As excited as I am about the prospect of a completed Mozilla browser, I cannot
deploy any E-Mail solution to my end users without LDAP support built into the
addressing.  You will be forcing me, and folks like me, to choose between
keeping users at 4.7 or finding some other E-Mail solution that will meet the
basic needs that Netscape itself helped to get going.

Before you guys go into a feature freeze, I'm begging you to keep us corporate
users in mind.
cc: kmurray.  I think there are a few LDAP support bugs filed by Phil already.

reassigning to nobody@mozilla.org and putting helpwanted keyword. There are 
probably a bunch of bugs that this is a dup of.

We understand that LDAP is a feature that many people will miss but it is not 
currently on our schedule for this release.
Assignee: putterman → nobody
Keywords: helpwanted
This is going to be more than just a missed feature.  This will be a blocker to
anyone utilizing a corporate mail server.  Are there any that don't use LDAP as
their addressing backbone?

If you've ignored everything else I've ranted on about, please at least note
this one point.  There is not going to be any IT managers out there that can
deploy Mozilla as a mail client without this. This is much more than just a wiz
bang that didn't make it into the final build.

Without LDAP support, Mozilla can pretty much write off corporate users entirely.

FYI, I am working on basic LDAP protocol support and will also be doing an RDF
interface, so some of the underlying pieces required for this will hopefully be
there after a while. 
dmose,

Okay, now I'm really going to put my foot in my mouth.  Is there any part of
this that I can assist with?  I'm not a C++ programmer by any means, though I'm
not entirely lost on the syntax.  I am a web developer who can get around
JavaScript and PHP pretty readily, as well as a healthy bit of graphics
experience.  Please drop me an E-Mail if there's anything you think I might be
able to assist with in helping to make this happen.

Adding myself to the cc: list as well.

The stuff that can be done at this moment requires C++ code.  However, there
will certainly be testing that can happen in the relatively near future,
probably including testing of access to LDAP stuff from Javascript.  Frank Tang
has encouraged me to try and break down a task list of LDAP stuff that needs to
happen, and I'll do that fairly soon and post in the newsgroups once I have.  At
that point it should be a bit more clear.
Again, please let me know if and when I can assist with anything on this end.  
As you may have guessed, I've got an LDAP server to play with.  Looking forward 
to any updates you may have, and standing by.
ZdNet has written an article about LDAP and Netscape
http://chkpt.zdnet.com/chkpt/xlinkproduct_reviews/http://www.zdnet.com/products/stories/reviews/0,4161,2637785,00.html

A nice quote from the article, "Netscape 6's lack of Lightweight Directory
Access Protocol support, will be a deathblow to the browser."

As a note, this quote invariably applies to Mozilla.

Dan, I know you've been doing a LOT of LDAP work over the last couple of months.  
Any chance we could get an update on what all you've been doing as to how it 
might relate to this bug?  Though it looks like it won't make it to RTM, it'd be 
nice to see where things are at with trying to bridge the gap between the Mork 
db and the LDAP connectivity you've been working on.
The easiest way to see the work that's happened on the LDAP front is to page
back through the status reports at <http://www.mozilla.org/status/>.  The short
summary is that most of the work lately has been going into the XPCOM wrapper
for the C SDK and ldap: URL handler.  I hope to get an early version (0.6?) of
the URL handler/wrapper released fairly soon.  While none of this code is going
to be shipped with Netscape's 6.0 RTM, my plan is to make a .xpi file that will
install on top of both Netscape 6 and Mozilla.
No longer blocks: 36557
No longer depends on: 36557
Ok, I just dumped all these LDAP bugs onto dependencies this bug.  If someone
wants to help sort them out go for it.
Depends on: 2678
I may also be able to find time to test any LDAP support. I have been LDAP
enabling a web Authoring system for one of our clients and have been using my
own LDAP address book for the last few years.

By the way - Siemens has over 500000 employees world wide (half a million), with
over 60% listed in the various Corporate Directories. Mail clients which are not
able to connect to the corporate directory will not be supported by our
infrastructure providers. I wasn't wanting to put you all under any pressure
though ;-).

No LDAP is sure going to hurt.  Eudora supports it, Outlook supports it,
Mulberry supports it, Communicator supports it, many web-based mail packages
such as IMP support it, but Mozilla drops it?

As a temporary workaround, would it at least be possible to drag-and-drop
mailto: urls from a webpage into the addressing field of a new message?  That
way you could at least use web-based LDAP lookups (and would be a nice feature
in its own right).  Right now you can click on a single mailto: to start a
message, but I don't see an easy way to add additional addresses without
manually typing them.  OR...  if a mailto: url is clicked on, and an existing
"new message" window is already open, add the address to the existing message
rather than start a new message.

Anyhow, those suggestions probably belong somewhere else, but would at least
make the lack of true LDAP support a little more bearable.
No longer depends on: 17884
Depends on: 59038
Seeing this bug has made my hopes for ever using Mozilla (Netscape6) diminish.
We rely heavily on the LDAP support that is included in Netscape 4.x for mail.
The lack of LDAP support basically kills any hope for us to move to Netscape6.
As other products improve its inevitable that we would move away from Netscape
because of this removed feature. I too hope that LDAP support is upgraded from
an enhancement to being assigned to a upcoming milestone release.
Tony, please check out <http://www.beonex.com/dev>.

Open source != free beer.
(Disclaimer: I run Beonex.)
Oracle Corp. has over 40000 employees worldwide. They all use Netscape Messenger
4.x for email, and they all access a corporate LDAP directory to search or
validate email addresses.

I think LDAP support is a very important feature for corporate users. It should
not be so difficult to implement. 
Ahem. Before this bug report turns into Bugzilla's equivalent of `The Rime of the 
Ancient Mariner', please note that filling it with comments about how important 
LDAP is to your organization will *not* get LDAP implemented any faster. If you 
want LDAP implemented faster, donate some programmers.

Matthew, when I initially got into arguing the point for LDAP support way back 
when, one of the things I heard back was that it was low on the priority list.  
Priorities are defined by the needs of the end user.  What myself, and these 
other users are trying to illustrate here is that we feel the priorities on 
other bits of functionality away from LDAP will stop Mozilla deployment dead in 
it's tracks for thousands, if not millions, of desktops.

Nobody is under the impression that complaining is going to cause programmers to 
code faster.  What we are trying to illustrate to Mozilla is the need to take 
another look at the order in which the priorities are now set.

Ben, I only wish you had put that financing plan together months ago.  The hard 
reality is that due to the lackluster acceptance of NS 6.0 it's going to be only 
that much harder to break away funding for something like this from corporate 
sponsors who are not relying on a strategic alliance with either Mozilla or 
Netscape.  One of the execs at my company downloaded NS 6.0 at home... not many 
kind words could be heard.  It may not be fair to put Mozilla and Netscape on 
the same page, but this ain't about what's fair.
> What we are trying to illustrate to Mozilla is the need to take

That's exactly your problem. Mozilla does no development. Entities *contributing
to* Mozilla do development. For Mailnews, at the moment, the complete list of
contributors seems to be: Netscape, me, adam@gimp.org. If you want to address
Netscape, you know which way to go. If you complain here and on the newsgroup
about "Mozilla", you basically yell at *me*.

> Ben, I only wish you had put that financing plan together months ago.

I did, see the newsgroup archive. I suggested to put to gether some money and
use sourcexchange or something similar as platform. I even pointed with my
finger at the loudest yellers, but they all shyed away. They always have reasons
not to pay. Back then, they were "too small", now it's "too late".

If you want to do something for LDAP support in Mozilla, *now* is the time to
act. I plan to write most basic LDAP support in the next months, but I need
financial sponsoring. So, contact the managers who might be interested to stay
non-Microsoft and point them to <http://www.beonex.com/dev>.

Enough complaining and advertizing on my part. It's up to you.

is this a duplicate of #17879?
brade, no, see the deps.
brade> is this a duplicate of #17879?

yes brade, reding the description and comments of bug 17879, seems to be the
same than this one.
No. It is not a DUP. This one is a meta bug, the other bug for one specific type
of LDAP support (there are many other ways of LDAP support than querying the
server via address book support, which is what bug 17879 is about). Please check
out the dependencies: Bug 17879 blocks on this one.
Keywords: meta
I've looked at the dependency tree and I don't see a bug for supporting ldap
URL's in the browser window. Should I create one?
Benjamin: you can if you like, though in fact, that code is already working and
mostly done.  It's not quite ready to be turned on in the default builds yet,
but hopefully it will be soon.  See
<http://www.mozilla.org/directory/xpcom.html> for details on how to build with
it turned on.

what's the posibility of getting this in for moz 0.8?  (i.e. nominating for
moz0.8/nsbeta1/yadda yadda yadda in the hopes of getting some love for this boog)
Jason, mozilla0.8: 0. After that: Bad, unless Netscape is so nice to implement
it or you are willing to pay for it <http://www.beonex.com/dev> or find people
who are.
(I am speaking of a nice front-end. dmose, as he already said, working on some
of the backend.)
This is really a hot issue to our company.Just while we are defending Netscape
against Microsoft IE / Outlook , the LDAP support is being taken out. When we
are forced to go to Outlook on the client side, we are also forced to go to
Microsoft exchange on server side. Netscape/IPlanet are going to throw their own
windows and the windows of all IT people in the field who adopted Netscape's
LDAP functionality and now are faced with this nightmare.  (why don't you just
copy/paste the code of ldap support from the 4.x code into this one)
I hate to take my vote away, but I have work to do, and don't care for the 
flames that drop in my inbox on a regular basis from being on the cc list for 
this bug.  I'll cross my fingers and hope my action will make others think twice 
before putting in their two bits.

Bugzilla is about working on the code.  It is not about feature list politics.
Would it make sense to set up a cosource request for this?

I'd like to see how the 'interest's (the money people want to give for this) add up.
And I'd like to know how much e.g. Ben Bucksch charges to get this done.

Of course, the exact definition of the request would have to be discussed.
E.g. the source must be open during development, who will be the authority
deciding the task is done (maybe the QA contact of this bug?), ...

See http://www.cosource.com/ for details - and: No, I'm not employed there, I
just like the idea behind their work.
On the other hand, cosource charge approximately 25% of the task value (for
exact numbers, see http://www.cosource.com/cgi-bin/cos.pl/bid/priceinfo, only
available if logged in)
Blocks: 67151
> I'd like to see how the 'interest's (the money people want to give for this)
> add up. And I'd like to know how much e.g. Ben Bucksch charges to get this
> done.

Bug 67151

Couldn't the OpenLDAP tools code like slapd/slurpd/ldapsearch be adapted for
this? Is there a licensing issue with doing this? Anyone interested in pursuing 
this approach along with me, please email me.
> Couldn't the OpenLDAP tools code like slapd/slurpd/ldapsearch be adapted for
> this?

No Need to do that, we have the C LDAP SDK, developed by Netscape. See
mozilla/directory/, IIRC.

Okay, the SDK gives me a framework but I'd still have to write some code. I'm 
just more familiar with the OpenLDAP code base. Is someone working on an XPCOM 
wrapper for this - then the mailnews people could just add some JavaScript 
chrome for the autocomplete just like the address book implementation.
Rick: yes, there's already an XPCOM wrapper for the LDAP C SDK in mozilla.  See
<http://www.mozilla.org/directory/xpcom.html> for more info about it.  In fact,
a number of folks are now starting work on various LDAP-related features in
mozilla; join the discussion in the .directory and .mailnews groups.
Assign to Hong's group
QA Contact: lchiang → hong
reassigning qa to yulian@netscape.com, assigning to jpm@netscape.com
Assignee: nobody → jpm
QA Contact: hong → yulian
Over to Dan :-)
Assignee: jpm → dmose
*** Bug 75794 has been marked as a duplicate of this bug. ***
Blocks: advocacybugs
Now that it seems LDAP integration is all in the mail composition (and VERY
nicely at that) are we at a point to where we can call this bug fixed?  Any
performance or functionality reasons to keep this bug open?
This turned into a meta-bug, see the dependencies. However, we know have a
Bugzilla Component for LDAP in Mailnews. So, closing thus bug makes sense IMO.
Status: NEW → ASSIGNED
Because this is indeed a meta-bug with information in its dependencies, I'd
prefer that we keep it open.  Note that LDAP is and will be used in other parts
of mozilla besides mail-news (autoconfig, ldap: urls at least).
what about duping this against bug 17880 which also is a meta bug....

Bug 17880 is for LDAP autocomplete only.  This bug tracks all LDAP-related
features in Mozilla, of which 17880 is one.
Blocks: 124140
Depends on: 126022
No longer depends on: 2769
No longer depends on: 126022
Blocks: majorbugs
Depends on: 116692
Hello,

Can anyone please check with 116692 it is a LDAP Schema, and it is now complete.

Thank You
Product: Browser → Seamonkey
No longer blocks: majorbugs
Component: Address Book → MailNews: Address Book
Product: Mozilla Application Suite → Core
QA Contact: yulian → addressbook
Assigning bugs that I'm not actively working on back to nobody; use SearchForThis as a search term if you want to delete all related bugmail at once.
Assignee: dmose → nobody
Status: ASSIGNED → NEW
Are there plans to add "write support", so that changes in Thunderbird addressbook which is linked to ldap server are written back to the directory server?
yes, there's an open bug on it, with a patch of work in progress.
Is there any hope for next TB generations? I don't see any activity anymore...
Flags: wanted-thunderbird3?
Flags: wanted-thunderbird3.0a1?
Flags: blocking-thunderbird3?
This is a meta bug tracking a whole bunch of different LDAP functionality in various sub-bugs.  LDAP is not major focus of Thunderbird 3, so it doesn't make sense for these (generally) to be either blocking or wanted.  It's conceivable that individual bugs could be blocking or wanted, but my current thinking is that that's not very likely unless they're quite severe or are sufficiently low hanging fruit.
Flags: wanted-thunderbird3?
Flags: wanted-thunderbird3.0a1?
Flags: wanted-thunderbird3.0a1-
Flags: wanted-thunderbird3-
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
Product: Core → MailNews Core
Priority: P3 → --
Summary: LDAP Support → [Meta] LDAP Support
Depends on: 550387
No longer depends on: 550387
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.