Re: LDAP C SDK

[Dan Mosedale]

[EMAIL PROTECTED] writes:
> -=-=-=-=-=-
> 
> I downloaded the C version of LDAP SDK but I am running into problems when 
> I compile it.  I was wondering if anyone has ever compiled the C version 
> or if you could understand the problem that  I am having.   Here is the 
> message I get when I compile:
> 
> [...]
>
> The name specified is not recognized as an
> internal or external command, operable program or batch file.
> NMAKE : fatal error U1077: 'C:\moz_tools\bin\makedep' : return code '0x1'
> Stop.

You need to download a few tools separately in order to build.
http://www.mozilla.org/directory/buildsdk.txt has pointers to all the
tools you need.

Dan

Re: LDAP C SDK

[Dan Mosedale]

"Karen Abou-Zeid" <[EMAIL PROTECTED]> writes:
> -=-=-=-=-=-
> 
> What about the Netscape-developed tools makedep.exe, txt2rc.exe, and
> waitfor.exe?  Do you know where these can be found?  

Go to  and follow the
"Windows Build Tools."

Dan

Re: Errors during installation ldap c sdk on redhat 6.2.

[Dan Mosedale]

[EMAIL PROTECTED] writes:
> Hi,
> 
> Ran into some errors when i tried to install the ldap c sdk.
>
> [...]
> 
> What's going on? Shouldn't I been using this milestone build (maybe too
> new), or .
> 
> Has anyone out there succeeded to build the shared libraries on red
> hat 6.2???

Actually, that build turns out to be rather old.  You'll probably be
happier if you check out the source code from CVS.  See
 for details.  To get LDAP
C SDK 4.0 code (you've got version 3.x), instead of using the CVS date
tag specified on that page, check out using the "-r
LDAPCSDK_40_BRANCH" switch to CVS.

Dan

Re: ldap url question...

[Dan Mosedale]

[EMAIL PROTECTED] writes:
> Hi,
> 
> Can anyone out there tell me whether it is possible to put authetication 
> information in a ldap uri, i.e. to bind (as a non-anonymous user) to a 
> directory server using a ldap uri??? 

It is possibly to specify this information with the "bindname"
extension.  And example would be

 ldap:///??sub??bindname=cn=Manager%2co=Foo

See RFC 2255 for details.

Note, however, that this is not yet widely implemented.  Netscape 4.x
doesn't support it, nor does the mozilla.org LDAP C SDK, nor the
mozilla browser URL handler (yet).

Dan

Re: LDAP RFC2254 filter implementation source code.

[Dan Mosedale]

End User <[EMAIL PROTECTED]> writes:
>
> Can someone point me to where I can get the source code for a RFC 2254
> LDAP Search Filter parser?
> 

Sure; the Mozilla LDAP C SDK contains one.  See
 for instructions on how
to check it out of CVS.  For best results, though, you can get a newer 
version by checking out with "-r LDAPCSDK_40_BRANCH" rather than with
the date tag suggested on that page.

Dan

Re: LDAP access in Mozilla

[Dan Mosedale]

John Marmion <[EMAIL PROTECTED]> writes:
> This mail was posted successfully to the mozilla mailist 
> yesterday but failed to make to the Netscape news group. 
> I have been advised to resend it..
>
> The following is a fragment from a question and reply which 
> was originally posted to the mailnews mailing list but this 
> is a more appropriate forum to follow up. I am a colleague of 
> Paul Sandoz here in Dublin who posted the original mail about
> 2 weeks ago which stated that we are looking at adding LDAP 
> access to Mozilla. 
> 
> Dan Mosedale reply stated that work was already 
> onging on LDAP RDF via  and that it 
> would be going back into the tree soon. 

Yeah, I'm still having some problems making it work for me, and am in
the midst of trying to shake them out.  I hope to get it fixed soon
and checked in.  If you need it immediately, let me know and I'll send 
it to you.

> I am interested in this. I am not specifically interested in
> the LDAP RDF datasource code but on the added LDAP code in general.
> I am enquiring into how this was implemented, what the idl looked 
> like, is the code a wrapper around the existing LDAP C-sdk etc. Is
> this code a follow up to the existing code in the directory/xpcom tree?
> When are we likely to see the code in the tree? 

Well, the RDF code itself is a Javascript component.  It lives in
directory/xpcom/datasource.  It calls into the code in
directory/xpcom/base for the actual LDAP work.  (Much of) the stuff in
directory/xpcom/base is in fact just an XPCOM wrapper around the LDAP C
SDK.  The IDL is in directory/xpcom/base/public.  All this stuff
should be browsable via http://lxr.mozilla.org/.

> This looks like it has similarities to the work we are 
> currently investigating and we would rather avail of existing 
> code than attempt to write our own and find out later that it
> is already implemented. Can Dan or Peter or anyone 
> fill me on the details of this. I would appreciate any clarification
> on this. Thanks in advance

Absolutely; coordinating our work would be a fine thing.  I'm in the
process of transitioning to a new job right now where I will be
working full-time on LDAP browser integration, so now is a great time
for us to try and make sure that our work intersects cleanly.

I noticed that someone from your group (Martin?) had posted some
addressbook-related IDL to one of the groups a while ago.  Is that
still relevant to your strategy?

Dan

[Fwd: LDAP access in Mozilla]

[Dan Mosedale]

[Forwarded with permission]



> Absolutely; coordinating our work would be a fine thing.  I'm in the
> process of transitioning to a new job right now where I will be
> working full-time on LDAP browser integration, so now is a great time
> for us to try and make sure that our work intersects cleanly.
> 
> I noticed that someone from your group (Martin?) had posted some
> addressbook-related IDL to one of the groups a while ago.  Is that
> still relevant to your strategy?
> 
> Dan
> 

Hi Dan,

Thanks for the prompt and warm response.

Yes, we would like to see the latest code. You can send it me. 
Currently we are looking at the existing LDAP XPCOM component 
stuff in the directory/xpcom with a view to using it. We would 
be more than willing to work alongside you. We will get back 
to you and to clarify any issues we have and see how we can 
cooperate.

Yes, I work with Paul and Martin. Paul is on vacation soon and I
have very recently joined the project after working on the OpenOffice
project. I am attaching Paul's latest summary of what we hope to do
and how we hope to do it. You can forget everything you have seen up
to now. The addressbook.idl strategy from Martin has now been dropped
in favour of attempting to use as much of the existing code in 
Mozilla as we can. Paul's strategy is now to separate the specific
database Address Code out so that the LDAP and address book data
sources could be added in. Have a look at Paul's document and feel
free to comment.

We see little or no development taking place in the Address Book
sources. We have attempted to find out and I was hoping to use 
this mail to see if you know different. Again, if there are plans
to add LDAP access to the address book, we would rather know now.

I will get back to you.


John.

 MozillaAddrBook.pdf

Re: PSM 2.0 and LDAP in the browser (was Re: PSM 2.0 (PIP) docs now available)

[Dan Mosedale]

"Nelson B. Bolyard" <[EMAIL PROTECTED]> writes:
> Dan Mosedale wrote:
> 
> > So one thing that would be helpful to those of us working on LDAP in
> > the browser is the ability to get access to some of the NSS
> > functionality for the LDAP C SDK to use.
> > 
> > LDAP in the browser consists of an XPCOM wrapper around the LDAP C
> > SDK, which does all the connection management for us under the hood.
> > The C SDK itself uses raw or NSPR sockets to do all the work, and I'm
> > told that the most recent version interacts with NSS 3.2 directly.
> 
> > Since we want to share as much code as possible, it would be really
> > good not to have to link the C SDK against a second copy of NSS
> > separate from PSM.  So in some ideal world, it seems like the LDAP
> > XPCOM wrapper would be able to ask PSM for some set of raw function
> > pointers to NSS functions which could then be passed into the LDAP C
> > SDK for use.
> > 
> > Comments?
> 
> The LDAP C sdk has always used NSS.  In the past, it actually linked its
> own copy of NSS into its DSO/DLL.  Now, in NSS 3.2, it will simply use the
> NSS DSO, and no longer have its own copy.
> 
> The LDAP C SDK developer is one of NSS's main Beta testers.

One of the interesting pieces here, as I understand it, is that PSM
doesn't use the NSS DSO; it statically links NSS because of an issue
related to the symbols that NSS exports.  So we'd have to ship two
copies of NSS with mozilla, which sort of defeats the code-sharing

Dan

Re: [Fwd: LDAP access in Mozilla]

[Dan Mosedale]

[EMAIL PROTECTED] (Ben Bucksch) writes:
> Dan Mosedale wrote:
> 
> > if there are plans
> > to add LDAP access to the address book, we would rather know now.
> 
> John, the best way to work at Mozilla is to post frequently to the 
> newsgroups and file or take over bugs in bugzilla for each task.

Heh; actually the main point of my forwarding that was that I thought
folks would be interested in the attached PDF.

> There is already an LDAP tracking bug - bug 36557.

I'll try and add some comments to that and related bugs in upcoming
days and weeks regarding what I and others at Netscape are working on
and trying to achieve...

Dan

Re: [Fwd: LDAP access in Mozilla]

[Dan Mosedale]

[EMAIL PROTECTED] (Dan Mosedale) writes:
> 
> [Forwarded with permission]
> 
> > Absolutely; coordinating our work would be a fine thing.  I'm in the
> > process of transitioning to a new job right now where I will be
> > working full-time on LDAP browser integration, so now is a great time
> > for us to try and make sure that our work intersects cleanly.
> > 
> > I noticed that someone from your group (Martin?) had posted some
> > addressbook-related IDL to one of the groups a while ago.  Is that
> > still relevant to your strategy?
> 
> Thanks for the prompt and warm response.
> 
> Yes, we would like to see the latest code. You can send it me. 

OK, I'll post the latest datasource in a followup to this thread.  As
was mentioned in an earlier discussion between Paul and me, the RDF
schema that the datasource uses is currently a bit different than the
existing addressbook schema.  The current datasource schema is
essentially a passthrough: any LDAP attribute is represented as an
identically named RDF property.  

It seems like it ought to be pretty easy to make the datasource have
attributes in both the existing passthrough namespace as well as the
NC-rdf namespace expected by the addressbook.  Probably just need to
add a translation table into the datasource.

> Currently we are looking at the existing LDAP XPCOM component 
> stuff in the directory/xpcom with a view to using it. 

Yes, this is the direction we're hoping things will proceed as well.

> We would be more than willing to work alongside you. We will get back 
> to you and to clarify any issues we have and see how we can 
> cooperate.

Fantastic!  I'll be posting more stuff here soon with more details
about our particular goals.  

> Yes, I work with Paul and Martin. Paul is on vacation soon and I
> have very recently joined the project after working on the OpenOffice
> project. I am attaching Paul's latest summary of what we hope to do
> and how we hope to do it. You can forget everything you have seen up
> to now. The addressbook.idl strategy from Martin has now been dropped
> in favour of attempting to use as much of the existing code in 
> Mozilla as we can. Paul's strategy is now to separate the specific
> database Address Code out so that the LDAP and address book data
> sources could be added in. Have a look at Paul's document and feel
> free to comment.

I like that strategy; leveraging the existing code seems like it should
get running code significantly sooner.  I haven't yet had a chance to
look at the PDF file; I'll try and do that tommorrow.

Dan

latest LDAP datasource (was Re: [Fwd: LDAP access in Mozilla])

[Dan Mosedale]

As requested by a few folks, here is the latest nsLDAPDataSource.js
file.  It is still not quite working, but getting there.

Peter: this version has a few edits since the one I sent you earlier
today (my time; I guess that'd be yesterday for you).  Since jband has
fixed 67258, I've removed debugging cruft related to that, added a few
more comments, and done some more whitespace tweaking.  However,
because all of the substantial code changes since the current CVS
revision are yours, would you like to do the honors and check it in so
that the cvsblame doesn't get horked?  After it gets checked in, I'll
be able to file another xpconnect bug that this tickles... :-)  

Dan

/* -*- Mode: Java; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*-
 * The contents of this file are subject to the Mozilla Public
 * License Version 1.1 (the "License"); you may not use this file
 * except in compliance with the License. You may obtain a copy of
 * the License at http://www.mozilla.org/MPL/
 * 
 * Software distributed under the License is distributed on an "AS
 * IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
 * implied. See the License for the specific language governing
 * rights and limitations under the License.
 * 
 * The Original Code is the mozilla.org LDAP RDF datasource.
 * 
 * The Initial Developer of the Original Code is Netscape
 * Communications Corporation.  Portions created by Netscape are 
 * Copyright (C) 2000 Netscape Communications Corporation.  All
 * Rights Reserved.
 * 
 * Contributor(s): Dan Mosedale <[EMAIL PROTECTED]>
 * Brendan Eich <[EMAIL PROTECTED]>
 * Peter Van der Beken <[EMAIL PROTECTED]>
 * 
 * Alternatively, the contents of this file may be used under the
 * terms of the GNU General Public License Version 2 or later (the
 * "GPL"), in which case the provisions of the GPL are applicable 
 * instead of those above.  If you wish to allow use of your 
 * version of this file only under the terms of the GPL and not to
 * allow others to use your version of this file under the MPL,
 * indicate your decision by deleting the provisions above and
 * replace them with the notice and other provisions required by
 * the GPL.  If you do not delete the provisions above, a recipient
 * may use your version of this file under either the MPL or the
 * GPL.
 */

const DEBUG = true;

// core RDF schema
//
const RDF_NAMESPACE_URI = "http://www.w3.org/1999/02/22-rdf-syntax-ns#";
const NC_NAMESPACE_URI = "http://home.netscape.com/NC-rdf#";
const LDAPATTR_NAMESPACE_URI = "http://www.mozilla.org/LDAPATTR-rdf#";

// RDF-specific success nsresults 
//
const NS_ERROR_RDF_BASE = 0x804f; // XXX is this right?
const NS_RDF_CURSOR_EMPTY = NS_ERROR_RDF_BASE + 1;
const NS_RDF_NO_VALUE = NS_ERROR_RDF_BASE + 2;
const NS_RDF_ASSERTION_ACCEPTED = Components.results.NS_OK;
const NS_RDF_ASSERTION_REJECTED = NS_ERROR_RDF_BASE + 3;

// some stuff from ldap.h
//
const LDAP_RES_BIND = 0x61;
const LDAP_RES_SEARCH_ENTRY = 0x64;
const LDAP_RES_SEARCH_RESULT = 0x65;

const NS_LDAP_SCOPE_BASE = 0;

// ArrayEnumerator courtesy of Brendan Eich <[EMAIL PROTECTED]>
//
function ArrayEnumerator(array) {
this.array = array;
this.index = 0;
}
ArrayEnumerator.prototype = {
hasMoreElements: function() { return this.index < this.array.length; },
getNext: function () { return (this.index < this.array.length) ?
   this.array[this.index++] : null; }
}

// nsISupportsArrayEnumerator
//
function nsISupportsArrayEnumerator(array) {
this.array = array;
this.index = 0;
}
nsISupportsArrayEnumerator.prototype = {
hasMoreElements: function() { return this.index < this.array.Count(); },
getNext: function () { return (this.index < this.array.Count()) ?
   this.array.GetElementAt(this.index++) : null; }
}

// the datasource object itself
//
const NS_LDAPDATASOURCE_CONTRACTID = 
'@mozilla.org/rdf/datasource;1?name=ldap';
const NS_LDAPDATASOURCE_CID =
Components.ID('{8da18684-6486-4a7e-b261-35331f3e7163}');

function nsLDAPDataSource() {}

nsLDAPDataSource.prototype = {

// who is watching us; XXX ok to use new Array?
mObserverList: new Array(),

// RDF property constants.  
//
// XXXdmose - can these can actually be statics (ie JS class
// properties rather than JS instance properties)?  or would that
// make it hard for the datasource and/or component to be GCed?
//
kRDF_instanceOf: {},
kNC_child: {},
mRdfSvc: {},

// since we implement multiple interfaces, we have to provide QI
//
QueryInterface: function(iid) {
  if (!iid.equals(Components.interfaces.nsISupports) &&
  !iid.equals(Components.interfaces.nsIRDFDataSource) &&
  !iid.equals(Components.interfaces.nsIRDFRemoteDataSource) &&
  

PSM 2.0 and LDAP in the browser (was Re: PSM 2.0 (PIP) docs now available)

[Dan Mosedale]

Bob Lord <[EMAIL PROTECTED]> writes:
> We've just posted the first draft of several PSM 2.0 (codename PIP) 
> documents.  In addition to the Roadmap which we posted a few days ago, 
> you'll now find the first cut at the workplan (a version of what we 
> internally call the 'PRD'), a tasklist, and a link to the UI mockups.
> 
> Start here:
> http://www.mozilla.org/projects/security/pki/psm/
> 
> These documents will evolve over the next few weeks as we learn more and 
> as Mozilla developers identify the areas where they'd like to help 
> (platform support, for example).
> 
> We're trying to release PIP by the end of May.  We'll soon post more 
> information about building PIP, as well as the target date for switching 
> the nightly builds over.

So one thing that would be helpful to those of us working on LDAP in
the browser is the ability to get access to some of the NSS
functionality for the LDAP C SDK to use.  

LDAP in the browser consists of an XPCOM wrapper around the LDAP C
SDK, which does all the connection management for us under the hood.
The C SDK itself uses raw or NSPR sockets to do all the work, and I'm
told that the most recent version interacts with NSS 3.2 directly.

Since we want to share as much code as possible, it would be really
good not to have to link the C SDK against a second copy of NSS
separate from PSM.  So in some ideal world, it seems like the LDAP
XPCOM wrapper would be able to ask PSM for some set of raw function
pointers to NSS functions which could then be passed into the LDAP C
SDK for use.

Comments?

Dan

Re: [Fwd: LDAP access in Mozilla]

[Dan Mosedale]

Michael Chui <[EMAIL PROTECTED]> writes:
> 
> Dan Mosedale wrote:
> 
> > > There is already an LDAP tracking bug - bug 36557.
> >
> > I'll try and add some comments to that and related bugs in upcoming
> > days and weeks regarding what I and others at Netscape are working on
> > and trying to achieve...
> 
> Does this mean there are Netscape engineers assigned to working on
> LDAP support in the addressbook and mail-news?  

Among other Mozilla contributors, yes.

Those of us at Netscape working on on it are still in the midst of
sorting out our priorities and timeframes.  There'll be more postings
here as that gets fleshed out.

> If so, it would be great to see updates on the following bugs (in
> addition to 36557 mentioned above):
>
> [FEATURE][LDAP] searching in address book (bug 17879)

I updated 36557 to mention that work is being done and that interested 
folks should watch the discussion in this newsgroups.  We should be
able to get some relevant web pages up in the relatively near future.
There should be more updates to these bugs in the days and weeks to
come.

> [FEATURE][LDAP] Autocomplete email address from LDAP directory (bug
> 17880)

Updated.

Dan

Re: [Fwd: LDAP access in Mozilla]

[Dan Mosedale]

[EMAIL PROTECTED] writes:
> Dan Mosedale wrote:
> >...
> >  Name: MozillaAddrBook.pdf
> >  Type: APPLICATION/pdf
> >MozillaAddrBook.pdf   Encoding: BASE64
> >   Description: MozillaAddrBook.pdf
> >...
> 
> Could an HTML version of this document be put on mozilla.org?
> 

I've got no objection to putting it up.  What do the authors of said
document think?

Dan

Re: [Fwd: LDAP access in Mozilla]

[Dan Mosedale]

John Marmion <[EMAIL PROTECTED]> writes:
> 
> I wanted to get back to you before the weekend to give you
> my very early impressions of using the XPCOM LDAP Wrapper. We will
> be very happy to use it. It looks like a solid bit of 
> engineering. 

Thanks!  Glad it looks to meet your needs.  We hope to soon set up a
bugzilla component for it so that there's a place to track bugs,
features requests, etc.

> I notice that it has Query only functionality and that it employs 
> ayschronous access. We will be hoping to add Add/Edit/Delete 
> functionality at some stage. But we can discuss these issues 
> later, at this point I am anxious to understand the 
> implementation. 

Yes, it should have more than query access.  Query acess just seemed
like the best first thing to implement.  Most of the focus has been on
asynchronous stuff thus far because there are relatively few places in
Mozilla where one can afford to stall out the current thread waiting
for network results to return.

> As usual for me I wrote a simple C program to access the XPCOM
> component. We have created a local LDAP Directory Server and I want
> to a pass in a URL select string and retrieve the corresponding
> entries:
> 
> 1. create a URL object
> 2. SetSpec
> 
> 3. Create Connection Object
> 4. Connection.Init using URL.host , URL.port etc..
> 
> 5. Create Operation Object 
> 6. Operation.Init(connection, ...MessageListener)
> 7. Operation.SimpleBind()
> 8. Operation.UrlSearch()

Last time I tried it, UrlSearch didn't really work right see the
comments in nsILDAPOperation.idl for a bit more info, as well as bug
44017.

> I am having difficulty in understanding the MessageListener 
> and the relationship with the Message Object --
> as I don't see how it is created. Typically what I want to
> is a UrlSearch followed by getting the attributes and results.
>
> Perhaps you can shed some light on this for me.. 

My initial plan was to try and use UrlSearch to do the work for
nsLDAPChannel.  But I eventually came to the conclusion that was
likely to cause me problems because its synchronicity problems and
because it wasn't really factored the way I wanted.

Basically, the nsIMessageListener is a callback interface that the
client of the XPCOM wrapper implements to get results from an async
operation.  Each time onLDAPMessage gets called, the parameter to that 
function is a newly created nsILDAPMessage, created by the XPCOM
wrapper as the corresponding protocol message arrived from the server.

For a more-or-less working example of some of this stuff, take a look
at nsLDAPChannel, especially the AsyncRead, and OnLDAP* methods.

Dan

online meeting about addressbook & ldap issues

[Dan Mosedale]

I've proposed to a few folks that those interested get together online soon
to discuss various technical addressbook and LDAP related issues.  How does
10:00 AM Pacific Standard Time (==  18:00 UTC) this Thursday (Feb 8) 
in channel #addressbook on irc.mozilla.org work for people?

Dan

Re: online meeting about addressbook & ldap issues

[Dan Mosedale]

[EMAIL PROTECTED] (Dan Mosedale) writes:
> 
> I've proposed to a few folks that those interested get together online soon
> to discuss various technical addressbook and LDAP related issues.  How does
> 10:00 AM Pacific Standard Time (==  18:00 UTC) this Thursday (Feb 8) 
> in channel #addressbook on irc.mozilla.org work for people?

Following up to myself so this hits .mail-news as well.

Dan

Re: [Fwd: LDAP access in Mozilla]

[Dan Mosedale]

[EMAIL PROTECTED] writes:
> Dan Mosedale wrote:
> >...
> >  Name: MozillaAddrBook.pdf
> >  Type: APPLICATION/pdf
> >MozillaAddrBook.pdf   Encoding: BASE64
> >   Description: MozillaAddrBook.pdf
> >...
> 
> Could an HTML version of this document be put on mozilla.org?

Done; thanks to John and Csaba.  <http://www.mozilla.org/directory/>
has a link to it.

Dan

Re: online meeting about addressbook & ldap issues

[Dan Mosedale]

Gervase Markham <[EMAIL PROTECTED]> writes:
> > I've proposed to a few folks that those interested get together online soon
> > to discuss various technical addressbook and LDAP related issues.  How does
> > 10:00 AM Pacific Standard Time (==  18:00 UTC) this Thursday (Feb 8)
> > in channel #addressbook on irc.mozilla.org work for people?
> 
> Did this happen? I couldn't get through to irc.mozilla.org...
> 

Yeah, I'll try and post notes soon.

Dan

Re: LDAP acces

[Dan Mosedale]

[EMAIL PROTECTED] (Csaba Borbola) writes:
> Dan,
> 
> I would like to know, what are the following entries in the prefs.js
> files doing among the ldap2.servers settings:
> 
> netcenter
> infospace
> verisign
> 
> They are always there and even the dirType settings is not stored in the
> preferences file, they have LDAPDirectory dirType, when they are in the
> memory. Why?
> I just would like to know, because I am going to use that dirType for
> the LDAP directory servers or should I introduce a new dirType for my
> LDAP directory entries?

I suspect that these entries are generated by old crufty code hanging
around from 4.x days.  It's probably completely unused at the moment.
I've added .mail-news to this posting in the hopes that someone there
might remember it's origin

Dan

posting irc meeting log

[Dan Mosedale]

I'd like to post the log to the meeting that we had in #addressbook on 
the 8th to www.mozilla.org.  If I don't hear any objections by Wednesday 
the 14th, I'll go ahead and post it.  So let me know if this poses a 
problem for you.

If anyone has email addresses for and/or can forward this message to 
James @ Sun Ireland, rsr411 (Dick Rhoads), and David, that would be 
greatly appreciated.

Thanks
Dan

LDAP browser integration page on www.mozilla.org w/eClient meeting minutes

[Dan Mosedale]

At , I've posted an LDAP 
browser integration page with a number of different documents and 
links.  If you know of or have more stuff that should be there, feel 
free to send me mail or check in directly to the doc tree yourself.

There are some meeting minutes from a couple of meetings the eClient 
group had, and I hope to have a log from the IRC meeting last week up soon.

Dan

Re: [Fwd: LDAP access in Mozilla]

[Dan Mosedale]

John Marmion <[EMAIL PROTECTED]> writes:
> Hi Dan,
> 
> I managed top sort out the MessageListener functionality 
> and get a simple implementation working. I used the 
> nsLDAPChannel code as a guide. Was this meant as an 
> example or to be used as is? Anyway, I have a couple
> of further queries to ask you. 

Well, the channel code is working code that will run display ldap:
URLs in the browser, which is why it was written.  But some of the
error-handling, cancellation code, and cleanup code is undone and/or
has thread-safety problems.  Leif and I will be looking into
resurrecting the current unused nsLDAPService so that it manages and
cleans up connections better, which will make it easier to get
nsLDAPChannel doing the right thing.

> I notice that on the return from the SimpleBind that you
> call the SearchExt(). I wondered why you did it that way as
> opposed to having an explicit SearchExt() call. 

Two reasons:

* LDAPv2 requires a bind before any other operation, and I hadn't
entirely decided on LDAPv2 vs. V3.  More on that later in this message.

* At some point, the channel should be able to support
authentication, which requires the bind step even in LDAPv3.

> Should we create a separate operation for each LDAP 
> request and share the connection object ?

Yes, that's how it's intended.  Furthermore, the nsLDAPService hacking
mentioned above will allow multiple clients of the XPCOM wrapper to
share a single connection.  When you want a connection, you'll ask the
service for one with a specific (host, port, bindname) tuple, and it
will give you back either an existing connection or create a new one.

> Should we be concerned about V2 and V3 of the LDAP
> implementation.

Leif and I were talking to Mark Smith (one of the LDAP C SDK wizards)
about this, and his suggestion was to try V3 to start, and fall back
to V2 if necessary.  Right now, we're not doing anything that requires 
V3 features, so this particular problem hasn't yet bubbled to the top
of our list.  The current code in nsLDAPConnection::Init() just uses
the default of V2.  I'll try and get Mark's permission to forward our
discussion to this list.

Dan

LDAP v2/v3 in the browser discussion

[Dan Mosedale]

Here's some discussion (reposted with permission) about supporting various
versions of LDAP in the browser.  Comments solicited...

Dan

Date: Tue, 06 Feb 2001 16:13:39 -0500
From: Mark Smith <[EMAIL PROTECTED]>
Subject: Re: LDAP v2 support in a Mozilla client?

Leif Hedstrom wrote:
> 
> Hi Mark,
> 
> quick question: Do you think that an LDAP extension to the Mozilla
> browser (addressbook, typedown addressing etc.) would have to work
> against an LDAP v2 only server? I mean, do we need to support such old
> servers, or is it ok to assume that most LDAP servers today will support
> LDAP v3?
> 
> Or, is it worthwhile to try to handle both cases properly?

I think some users will be disappointed if there is no support for
LDAPv2 at all.  But all of those users will be trying to talk to either
a really old LDAP server (U-M LDAP circa 1996 or earlier) or something
that uses OpenLDAP (which until fairly recently had no v3 support).

I think it would be very reasonable to only support some features or to
initially work only with LDAPv3.  Interested people can contribute
LDAPv2 support if it is really important.

Of course I don't have any real data about what servers people are
running against out there... I wonder if the fairly non-standard LDAP
servers such as Bigfoot et al support LDAPv3?

-Mark


Date: Tue, 06 Feb 2001 15:27:39 -0800
From: Leif Hedstrom <[EMAIL PROTECTED]>
Subject: Re: LDAP v2 support in a Mozilla client?

Mark Smith wrote:
>
> Of course I don't have any real data about what servers people are
> running against out there... I wonder if the fairly non-standard LDAP
> servers such as Bigfoot et al support LDAPv3?

That's a good question, maybe we can use Bigfoot and some of the other LDAP
enabled "white pages" systems as part of the QA test cycles?


Date: Thu, 08 Feb 2001 15:49:59 -0500
From: Mark Smith <[EMAIL PROTECTED]>
Subject: Re: LDAP v2 support in a Mozilla client?

Leif Hedstrom wrote:
> 
> Mark Smith wrote:
> 
> > I think it would be very reasonable to only support some features or to
> > initially work only with LDAPv3.  Interested people can contribute
> > LDAPv2 support if it is really important.
> >
> > Of course I don't have any real data about what servers people are
> > running against out there... I wonder if the fairly non-standard LDAP
> > servers such as Bigfoot et al support LDAPv3?
> 
> That's a good question, maybe we can use Bigfoot and some of the other LDAP
> enabled "white pages" systems as part of the QA test cycles?

Maybe.  I did a little "research" .  Raw results are attached -- I
basically ran the ldapsearch command (which tries an LDAPv3 bind by
default) against some LDAP servers I know about.  Many of these are
university sites since most .coms do not have a public LDAP directory. 
Here is the summary:

LDAPv3:
memberdir.netscape.com
directory.verisign.com
ldap.nyu.edu
directory.washington.edu
ldap.wvu.edu

LDAPv2 only:
ldap.whowhere.com
ldap.itd.umich.edu
ldap.tcs.tulane.edu

Hard to say for sure:
ldap.bigfoot.com (the v3 bind did not return an error)
ldap.infospace.com (connection refused)
ldap.switchboard.com (DNS lookup failed)

Note that BigFoot's LDAP server is just plain goofy.  It requires that
you bind.  And it ignores the search base and scope parameters
entirely.  But it does not refuse v3 binds.

-Mark
--2E03E3AE07E0384EC0B54916
Content-Type: text/plain; charset=us-ascii;
 name="public-ldap-servers-info.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="public-ldap-servers-info.txt"

Trying nsdirectory.mcom.com...
version: 1
dn:
namingContexts: dc=com
version: 1
dn: cn=monitor
version: Netscape-Directory/4.1 B99.262.2243

Trying memberdir.netscape.com...
version: 1
dn:
namingContexts: o=netcenter.com
version: 1
dn: cn=monitor
version: Netscape-Directory/4.1 B99.138.1723

Trying ldap.bigfoot.com...
ldap_search: Inappropriate matching
version: 1
dn: cn="Andy Monitor",[EMAIL PROTECTED],c=US,o=hotmail.com
mail: [EMAIL PROTECTED]
cn: Andy Monitor
o: hotmail.com
l: NORTHERN IRELAND
givenName: Andy
surname: Monitor

dn: cn="Bahrain Monitor",[EMAIL PROTECTED],c=US,o=hotmail.com
mail: [EMAIL PROTECTED]
cn: Bahrain Monitor
o: hotmail.com
givenName: Bahrain
surname: Monitor

dn: cn="Bernd Monitor",[EMAIL PROTECTED],c=US,o=mms.de
mail: [EMAIL PROTECTED]
cn: Bernd Monitor
o: mms.de
givenName: Bernd
surname: Monitor

dn: cn="BF Monitor",[EMAIL PROTECTED],c=US,o=com.net
mail: [EMAIL PROTECTED]
cn: BF Monitor
o: com.net
givenName: BF
surname: Monitor

dn: cn="BF Monitor",[EMAIL PROTECTED],c=US,o=bigfoot.com
mail: [EMAIL PROTECTED]
cn: BF Monitor
o: bigfoot.com
givenName: BF
surname: Monitor

dn: cn="BF Monitor",[EMAIL PROTECTED],c=US,o=local.bigfoot.com
mail: [EMAIL PROTECTED]
cn: BF Monitor
o: local.bigfoot.com
givenName: BF
surname: Monitor

dn: cn="BF Monitor",[EMAIL PROTECTED],c=US,o=sdgf.com
mail: [EMAIL PROTECTED]
cn: BF Monitor
o: 

ldap autocompletion impl details (was Re: posting irc meeting log)

[Dan Mosedale]

John Marmion <[EMAIL PROTECTED]> writes:
>  
> No problem for me. I wanted to follow up on the meeting and  
> take this opportunity to clarify the Autocompletion (typedown) 
> functionality that you are hoping to add. As part of our 
> requirements to add LDAP access to the address book, we had also 
> looked at implementing autocompletion. There exists in the addrbook/src/ 
> directory the nsAbAutoCompletion interface and as I understand it Paul's 
> proposal would make use of this. I want to find out if what you 
> are doing will go make use of this interface  or is it something 
> completely different. Will we be able to leverage anything from the 
> work you are doing. I would be grateful if you could clarify this
> for me. Thanks.

Paul's proposal doesn't seem to mention the autocomplete except in
passing, but it seems like it ought to (in theory) just continue to
work after the refactoring, but with Mork addressbooks _and_ LDAP
addressbooks.

However, I suspect that we're going to turn up parts of the existing
code that depend on the fact that Mork returns will be very quick
since they are completely local.  One possibly relevant problem is
that right now, the autocomplete menu has to be completely built at
once, since it's not RDF data accessed through a XUL template.  I
kinda of suspect that forcing the LDAP stuff through the existing
nsAbAutoCompleteSession code session is likely to accentuate that
problem.**

Additionally, Netscape management is very keen on seeing basic
autocompletion work done by Mozilla 0.9, which is quite soon
(~March 14th).  So I've concocted following strategy to that end: 

* write an nsLDAPAbAutoCompleteSession class, probably implementing from
nsIAbAutoCompleteSession to do the LDAP work. 

* write an nsICompositeAutoCompleteSession interface and a class that
implements it to allow the compose window to run multiple complete
sessions at once with the stuff in the local addressbooks taking
precedence over stuff in LDAP.

* at some point after that consider moving towards a more general RDF
solution, as outlined in the footnote below.

So I think the answer is that you might be able to leverage off part
of this short term solution (the compositing of autocomplete sessions), 
but that the Right Thing (moving to RDF) is likely to give you more
leverage.

Comments?  Thoughts?  Suggestions?

Dan

** Note that the autocomplete stuff is written in XBL, and at this
moment, XBL and XUL templates don't play nicely together.  Waterson
has been working on a fix for this (bug 39054), and once it gets
relanded in the tree (there was an aborted landing attempt last
night), it may then be reasonable to change the autocomplete
interfaces to use RDF for their data, which would allow RDF
assert()ing new entries into the menu as they arrive, as well as
perhaps obviating the need for the nsIAutoCompleteResults.idl
interface.

addressbook prefs UI change proposal; feedback requested (was Re: LDAP server preferences)

[Dan Mosedale]

[distribution widened, as I think .mail-news readers are likely to care 
about this]

Csaba Borbola wrote:

> Hi Dan,
> 
> thanks for the answers Kevin and Dan.
> I won't do much work this week, because I'm on a course.
> 
> My part in the LDAP address book project is to do the preferences.
> I would like to know, how did you think to do the preferences settings
> for the autocompletion.

A very timely question... a few of us eClient folks sat down just 
yesterday and came up with a straw-man proposal on this very thing.

> If you want to use the autocompletion, somewhere you have to specify the
> Directory Server settings, don't you? 

> Are you going to do the way as Netscape 4.x has?

What we came up with is something like what Netscape 4.x does, but put 
together in a way that fits into the Mozilla preferences style.  It has 
separate panes for Directory, Addressbook, and Autocompletion prefs, and 
we've started out only by specifying the Directory and Autocompletion 
panes, since that's what we're concentrating on first.


is an approximate description of what we came up with (unfortunately 
couched in my rather terse note-taking style).  We'd love to hear 
feedback from any and all corners, especially from the current Mozilla 
owners of the addressbook preferences UI.

> I did a short investigation at the beginning about the problem. This is
> really a short description. I attach that at the end of my mail.
> 
> So it would be really nice to clarify the overlapping tasks
> corresponding the preferences work, because there is no point to 
> do the same work twice.

Absolutely; I look forward to your comments.

> Thanks
> 
> 
> Csaba
> 
> 
> 
> 
> ***
> 
> LDAP related settings in Netscape 4.7:
> 
> In address book :
> Add directory menu point -> Dialog is asking for the followings:
> 
>   Description - name appearing in the left pane
>   LDAP server - name of the LDAP directory server
>   Server Root - this is the search base inside the directory tree
>   Port number - LDAP directory server port number
>   Max. number of hits - max number of matches for the query
>   
>   checkbox for login with name and password - if you tick it, the
> Netscape will drop you out a login name and password dialog
> box before connedcting the directory server
> 
>   checkbox for secure mode
> 
> 
> 
> Edit menu point -> Preferences -> Mail & Newsgroups -> Addressing
> 
>   Look for addresses in the following:
>   checkbox for local addressbook
>   checkbox for Directory server
>   drop down box for selecting from the installed directory servers
> 
>   When there are multiple addresses found:
>   show me a list of choices and accept what i have typed selective
>   radio buttons
>   checkbox for the case, if there is one match in autocompletion
> 
> 
> 
> ***
> 
> Classification of the features above:
> 
> The whole Addressing section in preferences is related to the
> autocompletion.
> 
> There are two types of preferences:
>  - one is stored in the prefs.js file in the ~/.mozilla/default
> directory
> 
>  - the other is stored in an other java script file, which is stored
> among the installed binary files (I'll call them hidden)
> 
> Almost all the autocompletion related settings are stored in the hidden
> preferences.

I guess I don't understand the point of the hidden file. Why not store 
all preferences in prefs.js?

> There are stored the following settings in the prefs.js file:
>   -autocompletion enabled
>   -csid (UTF-8)

What's a csid?

>   -description of the LDAP server
>   -filename of the adressbook file

For storing a local copy of the LDAP data?

>   -max. hits
>   -port number of LDAP server
>   -position of the addressbook in the adressbook list

>   -search base, ie. Server Root
>   -LDAP server name
> 

> 
> 
> I suggest to store the following extra preferences:
> 
>   - list of secondary ldap server in case of a not responding primary
> LDAP server

Is this necessary?  I would assume that when an admin has multiple LDAP 
servers, they'd just have multiple DNS A records pointing the single 
server name to multiple IP addresses, which would be returned in a 
single array by gethostbyname().

Dan

Re: addressbook prefs UI change proposal; feedback requested (was Re: LDAP server preferences)

[Dan Mosedale]

[EMAIL PROTECTED] (Csaba Borbola) writes:
> 
> > >   -csid (UTF-8)
> > 
> > What's a csid?
> 
> Additional ldapsearch parameters:
>  -i. Character set. Specifies the character set to use for command line
> input. The default is the character set specified in the LANG
> environment variable. You might want to use this parameter to perform
> the conversion from the specified character set to UTF8, thus overriding
> the environment variable setting. 
> Using this argument, you can input the bind DN, base DN, and the search
> filter pattern in the specified character set. ldapsearch converts the
> input from these arguments before it processes the search request. For
> example, -i no indicates that the bind DN, base DN, and search filter
> are provided in Norwegian. 

Ah, OK.  Yeah, this probably belongs as well, as well as some of the
other stuff in that iPlanet doc.  Unfortunately, we don't yet have a
good handle on all the i18n features we'll need to support.

> > >   -filename of the adressbook file
> > 
> > For storing a local copy of the LDAP data?
> 
> Netscape stores the last query in a local file, what you have even after
> restarting Netscape. It can have advantages and disadvantages too.

This seems like a reasonable thing to do.  I suspect this won't get
into our first cut, though, as we're trying to do the minimal set of
features necessary soas to get done in time.

> > Is this necessary?  I would assume that when an admin has multiple LDAP
> > servers, they'd just have multiple DNS A records pointing the single 
> > server name to multiple IP addresses, which would be returned in a 
> > single array by gethostbyname().
> 
> No. It isn't necessary. It can be a future preference. It is just a
> feature of the LDAP protocol, what we can use and we don't have to
> depend on admins.

Ah, good point.

Dan
-- 

Re: ldap autocompletion impl details (was Re: posting irc meeting log)

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> 
>   The initial idea was to unify autocomplete and
>   and connection to LDAP address books (corporate and personal)
>   though a query interface on the directory components.
>   A doQuery method on this interface would return an
>   enumeration of results, limited by a maximum (which
>   may be different for autocomplete and viewing a table
>   of addresses). The autcomplete component could then
>   check if the directory supports the query interface
>   and use this instead of obtaining each card.
>   Not sure if this is the best way. I have tended to think
>   in terms of interfaces and components instead of RDF data
>   sources (more on this later). Some notes on this idea
>   are attached.
>   This also should allow for efficient autocomplete on
>   other address book types, like outlook.
>   
> Dan Mosedale <[EMAIL PROTECTED]> writes:
> > 
> >Additionally, Netscape management is very keen on seeing basic
> >autocompletion work done by Mozilla 0.9, which is quite soon
> >(~March 14th).  So I've concocted following strategy to that end: 
> >
> >* write an nsLDAPAbAutoCompleteSession class, probably implementing from
> >nsIAbAutoCompleteSession to do the LDAP work. 
> >
> 
>   This, presumably, would kick of a search on all
>   LDAP address books that a user has set up.
>   i.e. would query the top level directory and obtained
>   a list of sub-directories with the approriate LDAP
>   addressbook scheme and use the URI (replace the addressbook
>   scehme with ldap:) on the RDF resource, or go directly though
>   the preferences.

It seems like it would be easier to code, though conceivably slightly
slower, if each LDAP address book were treated as a separate
autocomplete session to be composited.  Jean-Francois, any thoughts on this?

> >* write an nsICompositeAutoCompleteSession interface and a class that
> >implements it to allow the compose window to run multiple complete
> >sessions at once with the stuff in the local addressbooks taking
> >precedence over stuff in LDAP.
> >
> >* at some point after that consider moving towards a more general RDF
> >solution, as outlined in the footnote below.
> >
> 
>   Yes. We have been thinking about the relationship
>   between how data is obtained and how it is 'pumped'
>   through to XUL. To wait until all data is obtained
>   before returned, as you point out, is not good.

Yeah, I should actually give Jean-Francois Ducarroz credit for
pointing out this particular issue to me.  :-)

>   One thing i am having touble understanding
>   is the relationship between the LDAP RDF datasource
>   and the nsIAbDirectory and nsIAbCard interfaces
>   and implementations of.

Thus far, I've been mostly focussing on the autocomplete stuff and so
unfortunately don't have as good of a handle on the rest of the
addressbook.  Perhaps Candice Huang, whom I've CCed on this note, can
comment a little more on the use of RDF inside the addressbook code
and what directions she thinks might work...

>   We are in the process of writing an LDAP webtop 
>   implementation using the LDAP XPCOM directly.
>   We can be clever in how we return data by
>   implementing a class which is an enumerator
>   and also an LDAP message listener there by
>   (i assume!) allowing the object to be passed
>   up through the singular directory data source
>   without blocking until all results have been
>   obtained (e.g. get child cards). The same can
>   be done for querying.
>   I think the js datasource does somthing similar.
>   Just gotta make sure that the container (or queue)
>   which stores incomming results is guarded for re-entrant
>   code when entries are removed or obtained?

Sort of.  But part of the reason this works in the datasource is that
the users of the datasource are assumed to have an nsIRDFObserver
sitting around waiting for updates.  So if the results of a particular
query aren't already cached as an RDF delegate object, an empty
enumerator is returned, and the results are called back (unrelated to
the enumerator) with nsRDFObserver::onAssert() one at a time as they
arrive.  The only things that need to be threadsafe are the delegate
objects, and (I assume) the JS engine provides that threadsafety for
us under the covers.  But I could be wrong.  Peter V, can you confirm
or deny this?

>   I am in a bit of a dimlemma as to whether this
>   is the correct way to go forward. The refactoring
>   certianly makes it easier for *us* to implement new
&g

Re: Putting back the LDAP/Address Book refactored Code

[Dan Mosedale]

John Marmion <[EMAIL PROTECTED]> writes:
> Candice,
> 
> We are very anxious to begin and learn the process of putting
> back to Mozilla. After our discussion last week on the IRC, I 
> want to suggest the following and ask for your input.
> 
> As I said then, we want to ensure two things: 
> 
> 1. We do not break the build
> 2. We not break any existing functionality
> 
> After that:
> 
> 3. we want to add LDAP access to the Address Book.
> 
> Rather than waiting to put this all back at once. I wish to 
> propose that we attempt to put back the re-factored code only 
> at first i.e. with no added functionality. This would address 
> (1) and (2) above.
> 
> This would serve a number of issues. It would ensure that
> we have in place in the tree a hook to hang our new 
> added functionality and would also help us to appreciate 
> the process. It would also aid in people having confidence
> in our proposed changes.

This strikes me as a good strategy, in that it's generally
significantly easier to review smaller changes than larger ones.

> We would put this code back against LDAP BUG 36557. This initial 
> putback would not fix this but would pave the way for a later fix.
> Our timescale for this first putback is within the next 1-2 weeks.
> 
> We would wish to aid this process in whatever way that we can.

Ok, how about posting your changes as an attachment to bug 36557 in
patch form?  

Dan
-- 

mail-news meeting notes on the mozilla.org; log from ldap meeting on irc posted

[Dan Mosedale]

Some space has been created where folks can put meeting notes and/or 
logs related to  mail-news features.  In it I've posted a log from last 
weeks IRC meeting about mail/news LDAP integration.
See:

http://www.mozilla.org/mailnews/meetings/

Dan

Re: ldap autocompletion impl details (was Re: posting irc meeting log)

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> 
> Dan Mosedale <[EMAIL PROTECTED]> writes:
> >
> >>We are in the process of writing an LDAP webtop 
> >>implementation using the LDAP XPCOM directly.
> >>We can be clever in how we return data by
> >>implementing a class which is an enumerator
> >>and also an LDAP message listener there by
> >>(i assume!) allowing the object to be passed
> >>up through the singular directory data source
> >>without blocking until all results have been
> >>obtained (e.g. get child cards). The same can
> >>be done for querying.
> >>I think the js datasource does somthing similar.
> >>Just gotta make sure that the container (or queue)
> >>which stores incomming results is guarded for re-entrant
> >>code when entries are removed or obtained?
> >
> >Sort of.  But part of the reason this works in the datasource is that
> >the users of the datasource are assumed to have an nsIRDFObserver
> >sitting around waiting for updates.  So if the results of a particular
> >query aren't already cached as an RDF delegate object, an empty
> >enumerator is returned, and the results are called back (unrelated to
> >the enumerator) with nsRDFObserver::onAssert() one at a time as they
> >arrive.  The only things that need to be threadsafe are the delegate
> >objects, and (I assume) the JS engine provides that threadsafety for
> >us under the covers.  But I could be wrong.  Peter V, can you confirm
> >or deny this?
> >
> 
>   Ah, i understand more now.
>   The LDAP message listener components need to
>   be thread safe. Well in a C++ component XPCOM throws up
>   some warnings if i don't the use:
>   
>   NS_IMPL_THREADSAFE_ISUPPORTS
>   
>   macro, like in the LDAPChannel implementation.
>   I dunno much about the xpconnect stuff.
>   I think your assumption is correct.

Well, that takes care of making sure that AddRef and Release are done
in a threadsafe manner, and xpconnect does ensure that level of
thread-safety.  And JS itself (when compiled with multi-threading
support) probably provides more atomicity assurances (like getting and
setting vars).  But what I was hoping Peter V. could comment on was
whether any of the complex datastructures in the datasource need any
extra thread-safety guards.  My suspicion is that they're ok as is,
but I'd like to be sure...

>   The existing abdirectory data source (nsDirectoryDataSource.cpp)
>   does not 'exibit' this type of behaviour. This maybe one
>   of the caveats i alluded to in the posted document.
>   Methods on the nsIAbDirectory interface are sort of
>   synchronous, but asynchronisty (yuk word, sounds like
>   some anti-Jungian conspiracy!) is achieved through
>   adding listeners to an address book session which
>   propagates up calls to the RDF data source.
>   
>   I think for an initial implmentation of a personal LDAP
>   address book it may not be as important as a corporate
>   because there is likely to be less information (i.e. cards)
>   returned, but then again it also depends on response
>   time...
 
Yeah, hard to say.  That seems unlikely to be workable for the
organizational address book of any size, as you say.  There are
probably plenty of folks with personal address books of multiple
hundreds of cards, too.  And it's worth remembering that blocking
at all on the UI thread is a serious no-no, since that will stall out
layout in all open mozilla windows.  That's the reason that the
LDAP datasource is coded to run on the LDAP connection thread.

>   I have written a read only perosonal LDAP address book
>   (based on code from John) using the refactored framework
>   and am able to copy cards from the LDAP to the local in
>   the mozilla GUI.
>   See attached for code.
>   (this is still a bit of a hack still because the LDAP location
>   is hardcoded and the bootstrap (or address book directory
>   manager component explicitly instantiates this implementation
>   because there is no creation/preferences functionality yet).

Cool; thanks for posting the code.  Writing more comments as you go
would make it easier to read.  :-)

>   
>   This will not work for corporate LDAP address books
>   since there needs to be an associated query. 

I'm not sure what you mean by this; can you elaborate?

>   Since the corporate will be read only and will not support
>   mail lists many of the methods on the nsIAbDirectory
>   interface do not

Re: addressbook prefs UI change proposal; feedback requested (was Re: LDAP server preferences)

[Dan Mosedale]

Srilatha Moturi <[EMAIL PROTECTED]> writes:
> > > Jennifer, I looked at the screen shots and they are very different
> > > from what we had in the proposal.
> > >
> > >* Directory pane should be in the preferences either under
> > >  mail/news or Advanced. The directory pane will be same as
> > >  Directory Servers dialog you had in the screen shots plus an
> > >  Advanced button.
> > >
> > Do you mean in  the Global Preferences (Edit --> Preferences) or in the
> > Mail/News Account Settings dialogs (Edit --> Mail/News Account
> > Settings)?  I'm guessing you mean the Global Prefs.  I think it will be
> > very hard to users to find this here.  A problem that 4.x had is that
> > users selected which LDAP server they wanted to search against in the AB
> > pref panel, but it was completely unclear to them that they had to go to
> > a completely different place to setup or modify an LDAP server. (They
> > had to do this step first by using the menus in the AB.)  We should try
> > not to make this same mistake.  It should be clear from the place the
> > user selects the LDAP server they want to use, how to edit or add LDAP
> > servers.
> >
> > Hence, if you want users to enable/disable LDAP autocomplete and (in the
> > future) select which LDAP server to use, to be in the Mail/News Account
> > Settings per account, editing or creating LDAP servers should be an off
> > shoot of that setting not in a whole different location.
> 
> Actually we want to do enable/disable LDAP autocomplete in the
> mail/news account setting per account now(not future). 

So I've been thinking about this a bit, and it's a little unclear to
me whether the typedown preferences should be per-identity, rather
than just per-account.  The current UI prefs are confusing to me, in
that they don't permit multiple identities per account, even though
the underlying code supports it (and I suspect that many people would
find this useful).  Any thoughts on this?

> Then we have to put editing or creating LDAP servers in the typedown
> pane. This we will have one per mail/news account(Edit-> Mail/News
> Account Settings).  Dmose, Leif any comments on this.

Note that in the relatively near future, there will also be for LDAP
addressbooks (separate from LDAP autocomplete).  So that dialog will
also make use of the directory server configuration info.  So if the
typedown pane needs a button to edit that info, the addressbook pane
would too.  Is that ok?

Dan
-- 

Re: ldap autocompletion impl details (was Re: posting irc meeting log)

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
>   
> >>
> >>This will not work for corporate LDAP address books
> >>since there needs to be an associated query. 
> >
> >I'm not sure what you mean by this; can you elaborate?
> >
> 
>   A picture is worth a 1000 words?
>   See attached.
>   i.e. 4.x functionality.
>   
>   Hence the need for a query interface which
>   is able to return an enumeration of cards
>   (or perhaps URIs) or notify the RDF datasource

Which RDF datasource do you mean?

>   via the address book session from a doQuery
>   command on the data source.
>   
>   It is more complicated than the auto completion
>   but could be used for auto completion.
>   Attached is a new revision of the query intefaces.

Cool; comments below.

> >>About LDAP XPCOM usage:
> >>I am curious to know why a two stage operation process is
> >>used on queries. The first operation-listener listens on
> >>a bind and instantiates a new operation which performs
> >>the search.
> >
> >This is done because LDAPv2 clients, as well as any authenticated
> >clients (not yet implemented) require a bind operation before doing
> >any other LDAP operation.  There are plans to work on sharing LDAP
> >connections among clients, so if the wrapper already has a bound
> >connection, the bind operation will sometimes (in the future) just be
> >a no-op. 
> 
>   Ok.
>   I was wondering about the management of connections
>   and how 'pools' connections could be reused efficiently...

Well, the idea is to bring back nsLDAPService from the dead (it's
currently old unused code).  Whenever you need a connection, you'll
pass the service a tuple of (servername, port, bindname, passwd) or
somesuch, and then it will either create the connection for you and
hand it back, or else just hand back an existing connection.  After a
connection has been idle (ie noone is holding a strong ref to it) for
a while (5 minutes or so?), the service will cause it to be shut
down.  Perhaps the service should do the bind for the caller, I'm not
entirely sure.  It may depend on what sort of rebinding support we
need to provide.  Leif is going to be looking at this, so he may be
able to give you more insight here.

> interface nsIAbDirectoryQueryMatchItem
> {
>   /**
>* The type of match
>*  contains, does not contain
>*  is, is not
>*  begins with, ends with
>*  sounds like (?)

Sounds like seems like a good idea, since LDAP servers do support it.
Leif, do you know of other interesting stuff that LDAP supports that
might be worth making available here?

>*
>*/
>   attribute long match;

So is this attribute necessary because you need to know how to sort
the list of returned matches?  It seems like it would be a bit clearer 
to call this "type" or "matchType".

>   /**
>* The match value
>*
>* ? Should this be nsISupports
>* ? If so how do we represent
>* ? wstring values
>*/
>   attribute wstring matchValue;
> };

Using a string seems reasonable to me.  After all, if you need the
object that implements this interface to provide you with some other
interface, you can always QI to that second iface.

> interface nsIAbDirectoryQuery
> {
>   // ? Do we need supported match
>   // ? types

It seems like it; this is something that folks might want to specify
via a preference.

>   // ? Do we need a parameter to control
>   // ? how sub-directories are queried

I guess that depends on the UI you wish to provide.  Is there some
case where you might not want sub directories searched?

>   /**
>* Initiates a query on a directory and 
>* sub-directories for properties on cards
>*
>* @param matchProperties
>*  The properties and values to match
>*  Value could of type nsIAbDirectoryQueryMatchItem
>*  for matches other than ?contains?
>* @param matchItems
>*  Defines how multiple match items should
>*  be treated for a query result
>*  Match one or more
>*  Match all
>* @param returnProperties
>*  The properties that will be returned that
>*  result in a query result
>* ? Can this be represented as an array of strings
>* ? instead

Yes, it can.  And it would be nicer to folks accessing this interfaces 
from languages other than C++.  An example of how to do it is at 
http://lxr.mozilla.org/seamonkey/source/xpcom/threads/nsIProcess.idl

>* @param nsIAbDirectoryQueryResultListener
>*  The listener which will obtain individual
>*  query results
>* @param resultLimit
>*  No mo

[Fwd: my ldap locking problem]

[Dan Mosedale]

So we're not really concentrating on the problem that this message is 
written about.  But it _is_ some of the only documentation about the 
XPCOM wrapper code other than the IDL files and the LDAP C SDK doc set.

Dan




OK, so I've written up a bunch of text about how the LDAP code works and 
the particular problem I'm having related to calling out of module with 
a lock held.  I'd love to hear any suggestions you have related to this

Thanks,.
Dan



A few caveats about the code:
-
http://lxr.mozilla.org/seamonkey/source/directory/xpcom/TODO.txt is a
list of the known issues about the code.  The issues most relevant to
this particular discussion are probably: 

My current plan is to get rid of all the code in nsLDAPChannel.cpp for
INVOKE_LDAP_CALLBACKS_ON_MAIN_THREAD code (it defaults to 0 == off
already).

A lot of the code in xpcom/base/src is actually part of the XPCOM
wrapper and belongs there.  But not all of it is:
nsLDAPProtocolHandler* and nsLDAPChannel* are clients of the XPCOM
wrapper and should be in their own directory/module.  nsLDAPService is
part of the XPCOM wrapper, but it currently contains dead code; in the
not-too-distant future it will be resurrected to manage
sharing/caching of LDAP connections between multiple callers.

The code that's currently in nsLDAPChannel::Cancel has thread safety
problems, and is what I'm trying to fix.  

How the LDAP code works
---
There is a connection object is used to keep track of each LDAP server
connection, and it is accessed through the nsILDAPConnection.idl interface:
.

To use it, you create one and call the init() method on it.  This will
cause the connection object to spin up a thread:



which it uses to listen for operation results by looping around
ldap_result() (a call into the (threadsafe) LDAP C SDK).

Then you create an operation object, used through the
nsILDAPOperation.idl interface:

.

The operation object is initialized by calling its init() method,
which tells it the connection it will execute on, and passes in an
nsILDAPMessageListener interface, 

,

which is where the results get called back to.  After this, the actual
operation method to be executed (eg simpleBind, searchExt) is called,
which starts the operation.  This actually adds the operation in
question to the connection's list of pending operations, and then
calls into the (threadsafe) LDAP C SDK to start the operation.

Whenever a message from the server arrives, the connection thread
figures out which operation it belongs to, and then invokes the
onLDAPMessage method of the associated nsILDAPMessageListener
callback.  The callback is invoked on the connection thread, so that
it stays out of the way of UI stuff.

Worth mentioning is that unlike the other interfaces that have been
described so far, objects that implement the nsILDAPMessageListener
will generally be clients of the XPCOM wrapper for the LDAP C SDK, not
part of the wrapper.

nsLDAPChannel is an example such client, which is the protocol handler
for ldap: URLs.  Like many nsIChannels

the interesting stuff starts to happen when its asyncRead method 

is called.  

It creates an operation to simpleBind to the LDAP server, sets
mCurrentOperation to point to it, and then kicks it off.  Then, when
the bind has completed, the nsLDAPChannel object gets a callback, in
which it creates, points mCurrentOperation to, and kicks of the
searchExt() operation itself.  

When the channel is done, it needs to clean up the resources in use.
After the simpleBind is kicked off, almost all the remaining channel
code runs on the connection thread, meaning that almost all resources
are being used only from the connection thread.  The only code that
might still be executed on the main thread is the Cancel() function,
called to abort the channel, or the destructor (currently empty).

Rather than locking every resource that might be in use, it seems to
make more sense to simply cause the cleanup to happen on the
connection thread.  The problem I'm having involves how to do that.
In the near future, nsLDAPChannel won't be guaranteed to be the sole
user of the connection, so it only gets to abort its operation(s) off
the connection, not shutdown the connection itself (there will be an
nsLDAPService for worrying about that).

This is one of the main uses of the mCurrentOperation member variable
in nsLDAPChannel: it is the link to the currently running operation on

[Fwd: ldap autocompletion impl details (was Re: posting irc meeting log)]

[Dan Mosedale]

[Forwarded with permission]

Dan


Like I have already explain to you, my current concern
today is how to add in real time new result in the dropdownlist in order
to not make the user wait that we are done searching the LDAP before starting
showing results. I like the approach of Paul about having a common interface
to access multiple kind or addressbook. The way of doing that should be something
like that:
  <> [local addressbook][autocomplete widget] <> [adressbooksAutocompleteSession] <> [remote address book]  <> [other kind of AB]

The addressing widget communicate to an addressbook autocomplete session
via an nsIAutoCompleteSession then the AC session will deal with several
or type addressbook using a new common interface that still need to be defined.
The all should be asynchronous.

Also About using RDF, be conscious that RDF is very slow when you start dealing
with a lot of entries. We hare just removing RDF from the message 3 panes
and we are now able to process messages about 10 times faster than before.
RDF is great when you have only few entries which could be fine to represent
the result in autocomplete but should not used to iterate the LDAP directory
which could be huge.

some other comment here after...

Dan Mosedale wrote:
Paul Sandoz <[EMAIL PROTECTED]> writes:
  	The initial idea was to unify autocomplete and	and connection to LDAP address books (corporate and personal)	though a query interface on the directory components.	A doQuery method on this interface would return an	enumeration of results, limited by a maximum (which	may be different for autocomplete and viewing a table	of addresses). The autcomplete component could then	check if the directory supports the query interface	and use this instead of obtaining each card.	Not sure if this is the best way. I have tended to think	in terms of interfaces and components instead of RDF data	sources (more on this later). Some notes on this idea	are attached.	This also should allow for efficient autocomplete on	other address book types, like outlook.	Dan Mosedale <[EMAIL PROTECTED]> writes:	Additionally, Netscape management is very keen on seeing basicautocompletion work done by Mozilla 0.9, which is quite soon(~March 14th).  So I've concocted following strategy to that end: * write an nsLDAPAbAutoCompleteSession class, probably implementing fromnsIAbAutoCompleteSession to do the LDAP work. 	This, presumably, would kick of a search on all	LDAP address books that a user has set up.	i.e. would query the top level directory and obtained	a list of sub-directories with the approriate LDAP	addressbook scheme and use the URI (replace the addressbook	scehme with ldap:) on the RDF resource, or go directly though	the preferences.
  It seems like it would be easier to code, though conceivably slightlyslower, if each LDAP address book were treated as a separateautocomplete session to be composited.  Jean-Francois, any thoughts on this?
  
I think I have already answered this question. Yes we should show the result
of the search in local addressbook without to have to wait on LDAP which
could be very slow. For that we need to have only on autocomplete session
which implement several directory search simultaneous. Some LDAP are faster
than other therefore we should proceed them in parallel and not in serial.
  
* write an nsICompositeAutoCompleteSession interface and a class thatimplements it to allow the compose window to run multiple completesessions at once with the stuff in the local addressbooks takingprecedence over stuff in LDAP.* at some point after that consider moving towards a more general RDFsolution, as outlined in the footnote below.	Yes. We have been thinking about the relationship	between how data is obtained and how it is 'pumped'	through to XUL. To wait until all data is obtained	before returned, as you point out, is not good.
Yeah, I should actually give Jean-Francois Ducarroz credit forpointing out this particular issue to me.  :-)
	One thing i am having touble understanding	is the relationship between the LDAP RDF datasource	and the nsIAbDirectory and nsIAbCard interfaces	and implementations of.
  Thus far, I've been mostly focussing on the autocomplete stuff and sounfortunately don't have as good of a handle on the rest of theaddressbook.  Perhaps Candice Huang, whom I've CCed on this note, cancomment a little more on the use of RDF inside the addressbook codeand what directions she thinks might work...
  	We are in the process of writing an LDAP webtop 	implementation using the LDAP XPCOM directly.	We can be clever in how we return data by	implementing a class which is an enumerator	and also an LDAP message listener there by	(i assume!) allowing the object to be pas

Re: ldap autocompletion impl details (was Re: posting irc meeting log)

[Dan Mosedale]

Peter Van der Beken <[EMAIL PROTECTED]> writes:
> Hi Dan and Paul,
> 
> You should explain to me what your question about threadsafety is, 
> because I haven't followed the discussion really closely. The datasource 
> currently waits till the last entry is in before asserting every result 
> as a child of the search URI. 

I just wanted to be sure that you didn't know of any possible
threadsafety issues in the datasource.  The only thing that came to
mind as even a possibility was if there could be any problem regarding stuff 
like two threads trying to access an incompletely built complex
datastructure at the same time.  But my suspicion is that there's no
such problems.  

Dan
-- 

Re: Compiling C SDK on Solaris 7

[Dan Mosedale]

Malcolm Kerec <[EMAIL PROTECTED]> writes:
> Hi,
> 
> I've tried compiling as per the documentation but receive the following
> errors:
> 
> /opt/mozilla $ gmake -f directory/ldapsdk.mk build
> cd config; gmake
> gmake[1]: Entering directory `/opt/mozilla/config'
> ../config/SunOS5.7_sparc_DBG.OBJ/nsinstall -R -m 444
> SunOS5.7_sparc_DBG.OBJ/nsin
> stall ../dist/SunOS5.7_sparc_DBG.OBJ/bin
> ../config/SunOS5.7_sparc_DBG.OBJ/nsinstall -R -m 444
> SunOS5.7_sparc_DBG.OBJ/nsin
> stall ../dist/SunOS5.7_sparc_DBG.OBJ/bin
> gmake[1]: Leaving directory `/opt/mozilla/config'
> cd directory; gmake export libs install
> gmake[1]: Entering directory `/opt/mozilla/directory'
> gmake[2]: Entering directory `/opt/mozilla/directory/c-sdk/ldap'
>   cd build; gmake -f Makefile.client -w export
> gmake[3]: Entering directory `/opt/mozilla/directory/c-sdk/ldap/build'
> ../../../../config/SunOS5.7_sparc_DBG.OBJ/nsinstall -R -m 555
> SunOS5.7_sparc_DBG
> .OBJ/dirver ../../../../dist/SunOS5.7_sparc_DBG.OBJ/bin
> gmake[3]: Leaving directory `/opt/mozilla/directory/c-sdk/ldap/build'
>   cd include; gmake -f Makefile.client -w export
> gmake[3]: Entering directory `/opt/mozilla/directory/c-sdk/ldap/include'
> 
> gmake[3]: Makefile.client: No such file or directory
> gmake[3]: *** No rule to make target `Makefile.client'.  Stop.
> gmake[3]: Leaving directory `/opt/mozilla/directory/c-sdk/ldap/include'
>   cd libraries; gmake -f Makefile.client -w export
> gmake[3]: Entering directory
> `/opt/mozilla/directory/c-sdk/ldap/libraries'
> gmake[3]: Makefile.client: No such file or directory
> gmake[3]: *** No rule to make target `Makefile.client'.  Stop.
> gmake[3]: Leaving directory
> `/opt/mozilla/directory/c-sdk/ldap/libraries'
> gmake[2]: *** [export] Error 2
> gmake[2]: Leaving directory `/opt/mozilla/directory/c-sdk/ldap'
> gmake[1]: *** [export] Error 2
> gmake[1]: Leaving directory `/opt/mozilla/directory'
> gmake: *** [build] Error 2
> 
> Can anyone help?

Try checking out the CVS tag LDAPCSDK_40_BRANCH of the SDK, rather
than the date-based tag mentioned on www.mozilla.org.  That code is
newer and should build correctly on Solaris.

Dan
-- 

Re: addressbook prefs UI change proposal; feedback requested (was Re: LDAP server preferences)

[Dan Mosedale]

[EMAIL PROTECTED] (Csaba Borbola) writes:
> Dan Mosedale wrote:
>  
> > <http://www.mozilla.org/mailnews/specs/proposals/LDAPAddressingPrefs.html>
> > is an approximate description of what we came up with (unfortunately
> > couched in my rather terse note-taking style).  We'd love to hear
> > feedback from any and all corners, especially from the current Mozilla
> > owners of the addressbook preferences UI.
> 
> 
> Based on your document, you you would like to have a UI for the
> following
> settings an the preferences pane related to the Directory server:
> 
> Directory Name 
> Hostname 
> BaseDN
> Port number 
> Login Userid 
> Password 
> Search filter
> Scope 
> Don't return more than X results ?
> 
> Do you want to store all of them in the prefs.js file?
> 
> 
> We would like to have stored the following settings in the prefs.js
> file:
> Directory Name (description name)
> Hostname
> BaseDN
> Port number
> Max Number of hits
> Anonymous or User login
> Login name
> Secure mode or not
> csid
> URI
> 
> I would like to highlight the URI, which would play the role the type of
> the
> address book, would provide the filename for the local addressbook too
> and a lot
> of information we would put in it.
> For example:
> 
> abdirectorymdb://abook.mab
> 
> OR
> 
> ldap://chilli.sun.com@anonymous:389:50:CSID

The above does not look like a valid ldap URI to me.  I think that a
some amount of the information you want to store isn't currently
storable in a ldap URI.  Ie what's the 50?  Are CSID's allowed in LDAP 
URIs?  And the bind DN should live in the x-bindname extension, I
think.  So I don't think a URI by itself would be enough.

> There is an other issue as well: Presumable we would like to provide
> in the near future an Outlook direct accessibility from Mozilla. To
> support this, we will have to store some Outlook related preferences
> too and we have to provide some GUI too to get information in. This
> would be a really address book specific setting.  Does it change
> anything for you at the moment? Does it do any implication to the
> present preferences issue?

Adding a few extra preferences and/or an extra preference pane sounds
reasonable.  I don't think this has any particular architectural
implications.

Dan
-- 

Re: addressbook prefs UI change proposal; feedback requested (was Re: LDAP server preferences)

[Dan Mosedale]

[EMAIL PROTECTED] (Csaba Borbola) writes:
> Hi,
> 
> > We will store all the LDAP preferences in prefs.js
> 
> That is cool. The only question now is, how? Do you want to use the URI
> scheme to store, as suggested in the refactored code document ?
> (http://www.mozilla.org/directory/addrbook-refactoring-proposal.html)
> i.e. we should not store an ID, what kind of address book is stored or
> where is it stored. We would store only the URI, and this tells you what
> kind of addressbook it is. Also where is it stored in the memory, and if
> it is a personal addressbook what the corresponding filename is as well.
> What do you think?

Well, there maybe issues in the amount of information that a standard
LDAP URI can hold, as per the other message I just posted.  But doing
the new URI schemes suggested in the refactoring proposal might work.
Although maybe just changing the syntax of the existing abook: scheme
and putting the ldap || mdb || ... after the colon would help keep us
from polluting the URI scheme namespace too much.  After talking this
over with hixie and dbaron, I filed bug 69513; if adding more schemes
is the right thing to do, that will be relevant to how the new
schemes get named.

Dan
-- 

Re: addressbook prefs UI change proposal; feedback requested (was Re:LDAP server preferences)

[Dan Mosedale]

[EMAIL PROTECTED] writes:
> Dan Mosedale wrote:
> >...
> > So I've been thinking about this a bit, and it's a little unclear to
> > me whether the typedown preferences should be per-identity, rather
> > than just per-account.  The current UI prefs are confusing to me, in
> > that they don't permit multiple identities per account, even though
> > the underlying code supports it (and I suspect that many people would
> > find this useful).  Any thoughts on this?
> >...
> 
> Please don't have a three-level hierarchy (mail/news --> account
> -->identity). People will get lost. Just let people create multiple
> accounts which happen to use the same servers -- that would achieve the
> same thing, wouldn't it?

Yeah, that would work.

Added comments to bugzilla bug 41929 nominating it for mozilla 0.9.

Dan
-- 

IRC meeting about i18n issues in mozilla LDAP?

[Dan Mosedale]

Several of us are working on LDAP features in Mozilla, most immediately 
related to supporting LDAP typedown for (hopefully) Mozilla 0.9.  We 
have relatively little experience with Mozilla i18n issues, and would 
like to have a meeting on IRC (server irc.mozilla.org in #addressbook) 
to try and get all the issues that we need to deal with out on the 
table.  We'd really love it if (especially) those of you on the To: list 
of this message could join us to help get this stuff sorted out.  I'd 
like to suggest 10:00 AM PST (18:00 UTC) next Tuesday (Feb 27) as a 
possibility.  But if that doesn't work for folks, I'd suggest that time 
on any day next week.

Thanks,
Dan

Re: ldap autocompletion impl details (was Re: posting irc meeting log)

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> >> *
> >> */
> >>attribute long match;
> >
> >So is this attribute necessary because you need to know how to sort
> >the list of returned matches?  It seems like it would be a bit clearer 
> >to call this "type" or "matchType".
> >
> 
>   No its not about sorting its about how an item would be
>   compared (or 'matched') against an instance.
>   
>   e.g. Match 'first name' which CONTAINS 'paul'
>Match 'email' with REGEXP '^d.*@.*\.org$'
>Match  > 
>   
>   I originally called it 'matchType', changed it, changed it back
>   and re-changed it! Basically i am not sure.

Ah, ok.  The current addressbook autocomplete code tries a whole bunch
of different match types that are internally hardcoded.  I like your
strategy of making them parameterizable though.  For the current LDAP
autocomplete, my intent is to make it be parameterizable, but I
haven't really sorted out the details of exactly how yet.  In part,
this is because the LDAP autocomplete piece is likely to continue to
be useful outside of addressbook (eg if someone wanted to write a
bugzilla XUL front-end, they could use it there too).

> >> interface nsIAbDirectoryQuery
> >> {
> >>// ? Do we need supported match
> >>// ? types
> >
> >It seems like it; this is something that folks might want to specify
> >via a preference.
> >
> 
>   Hmm.. maybe its more to do with what an implemention
>   supports e.g. some implemetations may not support
>   regexp match so its not a user preference.

That's true, but it may also be relevant to have as a preference.  EG
for small LDAP directories, doing a soundex match may be reasonable,
but for enormous ones, it might not.

> >>// ? Do we need a parameter to control
> >>// ? how sub-directories are queried
> >
> >I guess that depends on the UI you wish to provide.  Is there some
> >case where you might not want sub directories searched?
> >
> 
>   I was thinking that the query interface could be used to
>   get child cards in an asynchronous manner, we know
>   when all have been received because the query result
>   will tell us. This is a response to the fact the the
>   nsIAbDirectory.getChildCards could be implemented
>   asychronously notifying RDF indirectly making it
>   impossible to know when all the cards have been
>   recieved.

Couldn't you just have the query code assert a "querycompleted"
property into the RDF datasource when it's done?  Then the absence or
presence of that property would be enough to know.

> >>/**
> >> * Initiates a query on a directory and 
> >> * sub-directories for properties on cards
> >> *
> >> * @param matchProperties
> >> *  The properties and values to match
> >> *  Value could of type nsIAbDirectoryQueryMatchItem
> >> *  for matches other than ?contains?
> >> * @param matchItems
> >> *  Defines how multiple match items should
> >> *  be treated for a query result
> >> *  Match one or more
> >> *  Match all
> >> * @param returnProperties
> >> *  The properties that will be returned that
> >> *  result in a query result
> >> * ? Can this be represented as an array of strings
> >> * ? instead
> >
> >Yes, it can.  And it would be nicer to folks accessing this interfaces 
> >from languages other than C++.  An example of how to do it is at 
> >http://lxr.mozilla.org/seamonkey/source/xpcom/threads/nsIProcess.idl
> >
> 
>   Yep. Ah!, i would also like the possibility to return
>   other types like nsIAbCard.
>   
>   Hmm... perhaps two methods are required. One for strings
>   and the other for more detailed information using the
>   nsIProperties interface.

Conceivably, although it's worth noting that you can return an array
of interfaces to JS just like you would return an array of strings.
So maybe dropping the strings method would be ok too.

> >> * @param nsIAbDirectoryQueryResultListener
> >> *  The listener which will obtain individual
> >> *  query results
> >> * @param resultLimit
> >> *  No more than 'limit' results will be returned
> >> */
> >>void doQuery (in nsIProperties searchProperties,
> >>in long matchItems,
> >>in nsISupportsArray returnProperties,
> >>in nsIAbDirectoryQueryResultListener,
> >>in long resultLimit);
> >> };
> >> 
> >
> >Should there be a "max number of hits to return" parameter here too?
> >
> 
>   Not sure i understand. I think that:
>  _
>   "max number of hits to return" = resultLimit
>
>   i.e. i don't understand the difference.

Oh; heh.  I must have had a brain-fart.  Never mind.  :-)

> >> interface nsIAbD

Re: addressbook prefs UI change proposal; feedback requested (was Re: LDAP server preferences)

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> [Resending; news server problems]
> 
> Dan Mosedale <[EMAIL PROTECTED]> writes:
> >Well, there maybe issues in the amount of information that a standard
> >LDAP URI can hold, as per the other message I just posted.  But doing
> >the new URI schemes suggested in the refactoring proposal might work.
> >Although maybe just changing the syntax of the existing abook: scheme
> >and putting the ldap || mdb || ... after the colon would help keep us
> >from polluting the URI scheme namespace too much.  After talking this
> >over with hixie and dbaron, I filed bug 69513; if adding more schemes
> >is the right thing to do, that will be relevant to how the new
> >schemes get named.
> >
> 
>   I don't think it is necessary to store all preferences
>   in the URI, the minimum to identify the type, location
>   and maybe user would suffice for LDAP. An interim
>   solution could be to maintain both in the preferences
>   reusing one preference attribute as the uri, a good
>   candidate would be 'filename'. Hmm... maybe not because
>   this is used to identify the off-line db file for ldap,
>   but there is no concept of offline for ldap yet +
>   the offline address book could be identified as a uri
>   as well... ramble ramble

Well, Leif and I did a bunch of design work on the nsLDAPService code
last Thursday, and we came to the conclusion that it would make the
most sense to stuff as much info as we can into LDAP URIs and store
that in the prefs (just converting old prefs to the new prefs format),
and just use an extra pref or two to augment that as necessary.  Leif
will be posting info from that meeting here soon.

>   
>   I presume at some point that this .js file is going
>   to change to RDF?, a general prefs editor using an RDF
>   schema could be interesting esp. for enterprise where
>   preferences could be stored in an LDAP server.
>   

An interesting idea.  I don't know of any such plans, but that's not
to say that there aren't any.  You might try asking in the .prefs
newsgroup.

>   Also i think that there is no need to impose the address
>   book name space on an organisational ldap preferences.
>   
>   We would like to instantiate nsIAbDirectory RDF resource
>   components through corresponding factory components
>   which have contract ids like:
>   
>   @mozilla.org/addressbook/directory-factory;1?type=ldap
>   @mozilla.org/addressbook/directory-factory;1?type=abmdbdirectory
>   @mozilla.org/addressbook/directory-factory;1?type=outlook
>   
>   An LDAP address book directory factory can return an
>   RDF resource component with a URI defined by the scheme
>   'abldapdirectory'

So shouldn't the first contract id use "type=ldapabldapdirectory"?  Or
I am misunderstanding how you mean to construct these contract ids?

>   Also perhaps the scheme 'abmdbdirectory' could be better
>   stored as 'moz-pab' in the preferences?

This seems reasonable to me.

>   It is possible to use the number defining the type
>   of address book i.e. type=0,  but i think that it is
>   really ugly. Or even uglier have a:
>   
>   if (dirType == 0)
>   else if
>   .
>   .
>   
>   
>   We can get by with the former 'ugly' as an interim solution.

Yeah; agreed that this seems unnecessarily ugly.

Dan
-- 

"LDAP XPCOM wrapper" -> "LDAP XPCOM SDK"; new bugzilla component

[Dan Mosedale]

I'd like to create a Bugzilla component (and eventually a despot 
component) for the stuff under mozilla/directory/xpcom.  While thinking 
about what to name it, it occurred to me that referring to it as just 
the wrapper is no longer accurrate, since it now does more than just 
wrap the C SDK: it provides an RDF datasource, and will soon provide an 
XPFE autocomplete session.

So the best name I've been able to come up with is the LDAP XPCOM SDK. 
Any objections to this name?  Proposals for something better?

Dan

Re: "LDAP XPCOM wrapper" -> "LDAP XPCOM SDK"; new bugzilla component

[Dan Mosedale]

[EMAIL PROTECTED] (Dan Mosedale) writes:
> I'd like to create a Bugzilla component (and eventually a despot 
> component) for the stuff under mozilla/directory/xpcom.  While thinking 
> about what to name it, it occurred to me that referring to it as just 
> the wrapper is no longer accurrate, since it now does more than just 
> wrap the C SDK: it provides an RDF datasource, and will soon provide an 
> XPFE autocomplete session.
> 
> So the best name I've been able to come up with is the LDAP XPCOM SDK. 
> Any objections to this name?  Proposals for something better?

Mark Smith suggested LDAP XPCOM Components, which also sounds ok to
me.  Any strong feelings either way?

Dan


-- 

Re: ldap autocompletion impl details (was Re: posting irc meeting log)

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> 
>   Attached is a revamped set of nsIAbDirectoryQuery*
>   interfaces. Decided the nsIProperties interface was
>   not suitable.
>   Considered using arrays but used nsISupportsArray
>   for corresponding attributes instead. 

Just out of curiousity, why?  The nsISupportsArray interface is only
not very scriptable, after all.

>   My UML knowledge is very limited, but i presume its
>   correct (I have used a really cool java based
>   UML editor called Argo,http://www.ArgoUML.org/,
>   plug plug) 

Got me; I've got no UML experience at all, so I have to confess to not
entirely understanding what relationships between the interfaces are
supposed to be represented by that diagram.

>   We plan to use this interface and do a MAPI outlook
>   implementation (in addition to implemeting the card and
>   directory interfaces) such that an Open Office SDBC driver
>   can be written to perform queries on address directories
>   from SQL statements and create result sets from these.
>   Open Office currently lacks address support so cannot
>   perform mail merges :-(
>   
>   This should also give a significant boost to getting
>   organisational LDAP address book functionality working
>   and integrated into the address book framework so that
>   equivalent 4.x functionality can be acheived.

Great; sounds like very worthwhile work.

>   FYI, here is an interesting submission which proposes
>   the representatint of vCard objects in RDF:
>   http://www.w3.org/Submission/2001/04/

That is interesting; thanks for the pointer.

> #include "nsISupports.idl"
> #include "nsISupportsArray.idl"
> 
> [scriptable, uuid(0E846276-1DD2-11B2-95AD-96B1397240AC)]
> interface nsIAbDirectoryQueryProperty : nsISupports
> {
>   /**
>* The property which should be matched
>*
>* For example 'primaryEmail' or 'homePhone'
>* for card properties.
>*
>* Two further properties are defined that 
>* do not exist as properties on a card.
>* 'card:URI' which represents the URI property
>* of the card as an RDF resource
>* 'card:nsIAbCard' which represents the interface
>* of a card component
>*
>*/
>   attribute string name;
> };
> 
> [scriptable, uuid(3A6E0C0C-1DD2-11B2-B23D-EA3A8CCB333C)]
> interface nsIAbDirectoryQueryPropertyValue : nsIAbDirectoryQueryProperty
> {
>   /**
>* The value of the property
>*
>*/
>   attribute wstring value;
> };

Does these actually need to be interfaces, or could they just be
passed around as wstrings?  And how come one of them is a string
rather than a wstring?

> [scriptable, uuid(418EEDA8-1DD2-11B2-8FB5-905EF30BC9F6)]
> interface nsIAbDirectoryQueryMatchItem : nsIAbDirectoryQueryProperty
> {
>   /**
>* List of defined match types
>*
>*/
>   const long matchContains= 0;
>   const long matchDoesNotContain  = 1;
>   const long matchIs  = 2;
>   const long matchIsNot   = 3;
>   const long matchBeginsWith  = 4;
>   const long matchEndsWith= 6;
>   const long matchSoundsLike  = 7;
>   const long matchRegExp  = 8;
> 
>   /**
>* The type of match, like 4.x search parameters
>*  contains, does not contain
>*  is, is not
>*  begins with, ends with
>*  sounds like (?)
>*
>*/
>   attribute long matchType;
> 
>   /**
>* The match value
>*
>*/
>   attribute wstring matchValue;
> };
> 
> [scriptable, uuid(41EC291E-1DD2-11B2-B583-C44757081F64)]
> interface nsIAbDirectoryQueryArguments : nsISupports
> {
>   /**
>* The list of match items which will
>* be matched against instances of
>* cards
>*
>* nsISupportsArray
>*
>*/
>   attribute nsISupportsArray matchItems;
> 
>   /**
>* List of defined match items types
>*
>*/
>   const long matchItemsOneOrMore  = 0;
>   const long matchItemsAll= 1;
>
> 
>   /**
>* Defines how multiple match items should
>* be treated for a query result
>*  Match one or more (or)
>*  Match all (and)
>*
>*/
>   attribute long matchItemsType
>
>   /**
>* Defines if sub directories should be
>* queried 
>*
>*/
>   attribute boolean querySubDirectories;
> 
>   /**
>* The list of properties which should
>* be returned if a match occurs on a card
>*
>* nsISupportsArray
>*
>*/
>   attribute nsISupportsArray returnProperties;
> };

Would it be worthwhile to design the interfaces to support bool

Re: addressbook prefs UI change proposal; feedback requested (was Re: LDAP server preferences)

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> 
> >>Also i think that there is no need to impose the address
> >>book name space on an organisational ldap preferences.
> >>
> >>We would like to instantiate nsIAbDirectory RDF resource
> >>components through corresponding factory components
> >>which have contract ids like:
> >>
> >>@mozilla.org/addressbook/directory-factory;1?type=ldap
> >>@mozilla.org/addressbook/directory-factory;1?type=abmdbdirectory
> >>@mozilla.org/addressbook/directory-factory;1?type=outlook
> >>
> >>An LDAP address book directory factory can return an
> >>RDF resource component with a URI defined by the scheme
> >>'abldapdirectory'
> >
> >So shouldn't the first contract id use "type=ldapabldapdirectory"?  Or
> >I am misunderstanding how you mean to construct these contract ids?
> >
> 
>   The plan would be somthing like:
>   o obtain the uri in the preferences,
>   o call somthing like GetDirectoryFactory (uri) on
> an address book factory interface
> - this would obtain the scheme prefix
>   @mozilla.org/addressbook/directory-factory;1?type=
>   to the scheme and instantiate the relevant
>   component to return which implements a directory
>   factory interface
> - We would then call CreateDirectory (pref properties...)
>   which returns a directory interface of an RDF
>   directory resource component which represents
>   the address book implementation.
>   
>   I was trying to distinguish between URIs used in the
>   preferences and URIs used for RDF resources. The LDAP
>   factory will return a RDF directory resource with the
>   URI scheme 'abldapdirectory'.

OK, this part I understand:

>   The LDAP preferences could be used by other clients which
>   are not interested in address books directories like the
>   LDAP auto-completion code. So I thought it was better to
>   keep the generic scheme and let the factories return more
>   specific schemes in line with the more specific functionality.

But what I don't get is if I'm looking for preferences unrelated to
the addressbook, why would I be going through something called
'@mozilla.org/addressbook/directory-factory...' to get them?  Sorry if 
I'm being overly slow here.

Dan
-- 

Re: Secondary LDAP server in Mozilla address book

[Dan Mosedale]

[added .mail-news to the Newsgroup line]

[EMAIL PROTECTED] writes:
> From our organization's point of view having a secondary ldap server to
> turn to for address completion or address book display is highly
> desirable in two cases:
> 
> (1) Failure of the first server
> (2) An optional additional search even if the first server is alive and well.
> 
> DNS changes don't meet our particular needs well for the first case. We
> we make extensive use of the failover ability in Netscape 4.75.

OK, can you file an RFE in bugzilla on [EMAIL PROTECTED] and cc
[EMAIL PROTECTED] and [EMAIL PROTECTED] for this?  Not sure if this
will make 0.9 or not; I suspect probably not.  But it sounds like a
reasonable feature.

> The second option is not currently available though we have been
> thinking about trying to achieve it through referrals.  In this regard
> we expect referrals to become an increasingly important source for
> address completion-- in our state, Wisconsin, both the University of
> Wisconsin and the state government will be implementing public ldap
> servers in the not too distant future.

Yes, I believe the structure that we've proposed should handle
multiple searches without have to resort to referrals.  Multiple
searches may or may not make it into 0.9 however.

> It also is a desirable feature to us to have the ability to customize
> the attributes displayed in the addressbook.

This is definitely further in the future than 0.9 (unless someone else
contributes code to do it sooner); but we do plan to implement this
too.

> Mind you, I am pleased to get anything into Mozilla, and thank those of
> you doing the work.  But I thought I ought to say what would be
> desirable to us.

Thanks; that's useful input.

Dan
-- 

Re: How do you link in SSL with the 4.X SDK?

[Dan Mosedale]

"Michael F. March" <[EMAIL PROTECTED]> writes:
> I have an addition to this question.. I am compiling the
> SDK from source from Mozilla.org.
> 
> "Michael F. March" <[EMAIL PROTECTED]> wrote in message
> 97jih0$[EMAIL PROTECTED]">news:97jih0$[EMAIL PROTECTED]...
> > Anyone have any pointers on this?
> >
> > I can not find any dox on this.

Unfortunately, the code to build the directory SDK with SSL hooks has
not yet landed on mozilla.org.  The hope is that that will happen in
the not too distant future, however, because we're going to need it in 
order to support LDAP-over-SSL in Mozilla (which will probably be a
post Mozilla 1.0 feature).

Dan
-- 

Re: C SDK problems using NDS 8.X

[Dan Mosedale]

[EMAIL PROTECTED] writes:
> We are experiencing problems when using the sdk with Novell NDS 8.x
> (Netware 5.1 SP2).
> 
> The search calls hang at random , although it functions well at most
> times.
> (may be after prolonged inactivity on a connection to the LDAP server,
> or other reasons not tracable).
> 
> Earlier postings in this newsgroup point to memory leaks when using
> Netscape SDK, and NDS. Apparently they report that  problem was
> eliminated by using Novell's SDK.
> 
> We are on a platform for which novell's ldap kit (& shared libraries) is
> not available (Compaq Alpha 4.0.x, unix)
> 
> The Netscape C ldapsdk does not seem to have updated since Dec 98.
> 
> Any suggestions ?
> 

A newer version can be had if you checkout LDAPCSDK_40_BRANCH from
CVS.

Dan


-- 

Re: ldap autocompletion impl details (was Re: posting irc meeting log)

[Dan Mosedale]

[added .xpcom to the Newsgroups line; perhaps the XPCOM folks will
have opinions on some of the items touched on here]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> 
> >Paul Sandoz <[EMAIL PROTECTED]> writes:
> >> 
> >>Attached is a revamped set of nsIAbDirectoryQuery*
> >>interfaces. Decided the nsIProperties interface was
> >>not suitable.
> >>Considered using arrays but used nsISupportsArray
> >>for corresponding attributes instead. 
> >
> >Just out of curiousity, why?  The nsISupportsArray interface is only
> >not very scriptable, after all.
> 
>   I know :-( i decided to go completely one
>   way to see how it looked, then could work
>   out how to make it easier for js.

Fair enough.  I also just added a comment to bug 66138 lobbying for
improving the scriptability of nsISupportsArray.  It sure would be
nice if there was some way to unify XPCOM arrays and
nsISupportsArrays, or, failing that, at least make the latter more
scriptable.  One could even imagine a world where in certain
circumstances, XPConnect could directly map an nsISupportsArray to a
JS array.

> >> #include "nsISupports.idl"
> >> #include "nsISupportsArray.idl"
> >> 
> >> [scriptable, uuid(0E846276-1DD2-11B2-95AD-96B1397240AC)]
> >> interface nsIAbDirectoryQueryProperty : nsISupports
> >> {
> >>/**
> >> * The property which should be matched
> >> *
> >> * For example 'primaryEmail' or 'homePhone'
> >> * for card properties.
> >> *
> >> * Two further properties are defined that 
> >> * do not exist as properties on a card.
> >> * 'card:URI' which represents the URI property
> >> * of the card as an RDF resource
> >> * 'card:nsIAbCard' which represents the interface
> >> * of a card component
> >> *
> >> */
> >>attribute string name;
> >> };
> >> 
> >> [scriptable, uuid(3A6E0C0C-1DD2-11B2-B23D-EA3A8CCB333C)]
> >> interface nsIAbDirectoryQueryPropertyValue : nsIAbDirectoryQueryProperty
> >> {
> >>/**
> >> * The value of the property
> >> *
> >> */
> >>attribute wstring value;
> >> };
> >
> >Does these actually need to be interfaces, or could they just be
> >passed around as wstrings?  And how come one of them is a string
> >rather than a wstring?
> >
> 
>   I was trying to ensure that the QueryMatchItem type could
>   also be treated as a Property type. This makes it easy
>   to reuse the QueryMatchItem for the returned properties
>   since what you are searching for is often what you want
>   returned.

Ah, that makes sense.

>   The string represents the property name which will never
>   require i18n support therefore i did not think it
>   needed to be a unicode string.
>   Is this a valid assumption?

Sounds reasonable to me; though my i18n fu is not yet strong.

>   One problem with XPCOM is that it is lacking an 'Any'
>   type (like CORBA_Any) which makes if difficult to
>   combine interfaces and basic, or built-in, types into
>   an array. I suppose i am used to this flexibilty.

Now I get it.

> >>/**
> >> * List of defined match items types
> >> *
> >> */
> >>const long matchItemsOneOrMore  = 0;
> >>const long matchItemsAll= 1;
> >>
> >
> >Would it be worthwhile to design the interfaces to support boolean
> >logic (and, or, not, precedence), to allow for future expansion?

I'm still curious to hear any thoughts you might have on the above
question.

>   Attached is a version with support for nsISupportsArray
>   and arrays. Additionally added an nsISupports attribute
>   to the QueryPropertyValue interface if a property
>   is associated with an interface (e.g. nsIAbCard).

Cool; it would be interesting to hear any comments on these from
Candice or Ducarroz...

> Thanks,
> Paul.
> 
> 
> | ? + ? = To question
> \
>Paul Sandoz
> x19219
> +353-1-8199219
>  
> 
> -=-=-=-=-=-
> 
> 
> #include "nsISupports.idl"
> #include "nsISupportsArray.idl"
> 
> [scriptable, uuid(0E846276-1DD2-11B2-95AD-96B1397240AC)]
> interface nsIAbDirectoryQueryProperty : nsISupports
> {
>   /**
>* The property which should be matched
>*
>* For example 'primaryEmail' or 'homePhone'
>* for card properties.
>*
>* Two further properties are defined that 
>* do not exist as properties on a card.
>* 'card:URI' which represents the URI property
>* of the card as an RDF resource
>* 'card:nsIAbCard' which represents the interface
>* of a card component
>*
>*/
>   attribute string name;
> };
> 
> [scriptable, uuid(3A6E0C0C-1DD2-11B2-B23D-EA3A8CCB333C)]
> interface nsIAbDirectoryQueryPropertyValue : nsIAbDirectoryQueryProperty
> {
>   /**
>* The value of the property
>*
>*/
>   readonly attribute wstring value;
>   
>   /**
>* The value of the property
>* as an interfac

Re: addressbook prefs UI change proposal; feedback requested (was Re: LDAP server preferences)

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> 
> >>The LDAP preferences could be used by other clients which
> >>are not interested in address books directories like the
> >>LDAP auto-completion code. So I thought it was better to
> >>keep the generic scheme and let the factories return more
> >>specific schemes in line with the more specific functionality.
> >
> >But what I don't get is if I'm looking for preferences unrelated to
> >the addressbook, why would I be going through something called
> >'@mozilla.org/addressbook/directory-factory...' to get them?  Sorry if 
> >I'm being overly slow here.
> >
> 
>   I'm confused now!
>   I don't think i am explaining things all that well.
> 
>   The '@mozilla.org/addressbook/directory-factory...' string
>   is used to instantiate nsIAbDirectory componentes given
>   a uri and a set of other preferences defined as name value
>   pairs. We have designed a boot strap directory component
>   which is reposnsible for creating directory implementations
>   (top level address books) from the preferences. This
>   is where the factories will be used (we have yet to
>   implement this bit, but should not take long)
>   (we also need a way of getting notified when new
>LDAP address books have been created in the preferences).
>   The idea is to hide how/where the preferences are stored
>   from the address book directory implementations.
>   
>   So its the other way around, other clients can interpret
>   preferences how they wish without being imposed on by
>   address book semantics, i.e 'abldapdirectory'

OK, thanks.  I think I get it now: you're using it as a layer of
indirection to keep out unnecessary dependencies on the specific
preferences used.  A fine goal; we're also trying to keep the LDAP XPCOM
SDK (formerly known as the wrapper) from depending on preferences at
all.

Dan
-- 

Re: LDAP acces

[Dan Mosedale]

Phil Peterson <[EMAIL PROTECTED]> writes:
> David Durkee wrote:
> 
> > Dear Csaba, Dan and Kevin,
> > 
> > IMHO you will probably find the following link helpful:
> > http://docs.iplanet.com/docs/manuals/communicator/ldap45.htm
> 
> Hey, someone actually reads that stuff. Cool!
> 
> > ) Which leads to the second issue, which I think is that at least in
> > Netscape there are many "default" settings that can be changed in the
> > pref.js file if a new setting is specified. BUT they do not need to be
> > specified because they are "obviously" default. (you must love
> > self-documenting code) 
> 
> This is a pretty important point. As you can see in the doc above, the 
> 4.x LDAP preferences have a *ton* of different settings which can be 
> specified in the prefs infrastructure (netscape.cfg, all.js, prefs.js). 
> The LDAP prefs C code (libmisc/dirprefs.c) goes to great length to avoid 
> dumping default values into the prefs.js file, which would bloat the 
> file considerably, making it harder to read and slower to parse.

This is very good to know.

> Of course, the compiled-in prefs files make it easy to avoid putting 
> default values in the prefs file *if* you know the name of the pref at 
> compile-time, but since the LDAP pref names are dynamically generated, 
> we had all that yucky C code to do the same thing.
>
> I think alecf and/or sspitzer solved that problem in a parallel way for 
> mail/news accounts in mozilla (although I do see some bloat in my prefs 
> file).

To some extent, we're starting over with a new set of prefs, largely
stored in URI format.  But once we get to the point of working on the
more advanced preferences, we'll see what parts of the 4.x pref set we
can keep using.  And perhaps bug alec or seth to find out more about
their strategy.  :-)

> -- Phil. (LDAP alumnus scanning the group at dmose's request)

Muchas gracias; this is exactly the sort of help I was hoping for!

Dan


-- 

"Directory / LDAP XPCOM SDK" bugzilla component created

[Dan Mosedale]

The LDAP XPCOM SDK component of the Directory product has been created 
in Bugzilla.  I went with "LDAP XPCOM SDK" rather than "LDAP XPCOM
Components" because this batch of code is intended to provide
relatively generic LDAP building block functionality... and if someone 
were to implement more advanced LDAP stuff in other XPCOM components
in the mozilla.org tree in the future, having something called "LDAP
XPCOM Components" would be likely to lead to confusion.

Dan

-- 

Re: Problem compiling SDK on a Linux box

[Dan Mosedale]

"Christian Pinheiro" <[EMAIL PROTECTED]> writes:
> Hi Folks,
> 
> I installed PerLDAP a lot of times on a Solaris box without any problems,
> but now I'm having trouble on a Linux box (which I thought would be easier).
> Following the version of my server, and the error:
> 
> == LINUX ===
> Linux brcotia02.cidadei.com.br 2.2.16-22 #1 Tue Aug 22 16:49:06 EDT 2000
> i686 unknown
> 
> == GMAKE ===
> 
> GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
> Built for i386-redhat-linux-gnu
> Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000
> 
> ===C-SDK===
> 
> 1375703 Mar  6 17:39 ldapsdk_12311998.tar.gz
> 
> 
> 
> Well, now the error. After setting the environment variables, as the
> build.txt says, I get the following error:
> 
> [root@brcotia02 /INST_PATH]# cd mozilla
> [root@brcotia02 mozilla]# gmake -f directory/ldapsdk.mk build
> cd config; gmake
> gmake[1]: Entering directory `/INST_PATH/mozilla/config'
> cd ../config/mkdetect; gmake
> gmake[2]: Entering directory `/INST_PATH/mozilla/config/mkdetect'
> Generating detect_brcotia02_gen.mk.
> gmake[2]: Leaving directory `/INST_PATH/mozilla/config/mkdetect'
> gmake[1]: Leaving directory `/INST_PATH/mozilla/config'
> gmake[1]: Entering directory `/INST_PATH/mozilla/config'
> ../config/mkdetect/detect_brcotia02_gen.mk:24: *** missing separator.  Stop.
> gmake[1]: Leaving directory `/INST_PATH/mozilla/config'
> gmake: *** [build] Error 2
> 
> 
> =
> 
> When I look to the line 24 of this detect_brcotia02_gen.mk file, I see:
> 
> MOZILLA_XFE_MOTIF_INCLUDE_FLAGS =
> Could not find  anywhere on your system. <<<== LINE 24
> MOZILLA_XFE_MOTIF_HAVE_STATIC_LIB = 1
> MOZILLA_XFE_MOTIF_STATIC_FLAGS =
> Could not find  anywhere on your system.
> MOZILLA_XFE_MOTIF_HAVE_DYNAMIC_LIB = 1
> MOZILLA_XFE_MOTIF_DYNAMIC_PATHS =
> Could not find  anywhere on your system.
> MOZILLA_XFE_MOTIF_DYNAMIC_FLAGS =
> Could not find  anywhere on your system.
> 
> 
> 
> But I can't understand. It appears to be required to have MOTIF in my box,
> so why there is an detect_motif.sh on this SDK?

The CVS tip for the LDAP C SDK is messed up.  Try checking out the
LDAPCSDK_40_BRANCH instead of the date tag mentioned on the web page.

Dan



-- 

Re: Typedown prefs

[Dan Mosedale]

[EMAIL PROTECTED] (Csaba Borbola) writes:
> Dan,
> 
> do you have any final docs or list of preferences you would like
> to store for typedown? You told me, that you had been waiting for
> some marketing decision related to the UI for preferences. If you
> have some kind of finalized plan can you let me know so we can
> make some plans here. 
> 

Urgh, sorry I forgot to get back to you on this!  Something was, in
fact, sorted out on the Netscape end, but I don't know the specifics
on what preferences we ended up with.  Srilatha, can you post the
details?

Dan
-- 

Re: Installing Mozilla on Linux 7.0

[Dan Mosedale]

"Thomas" <[EMAIL PROTECTED]> writes:
> I've made all the changes in /etc/profile
> 
> MOZILLA_CLIENT=1
> NO_MDUPDATE=1
> MOZ_LDAP_SDK=1
> export MOZILLA_CLIENT NO_MDUPDATE MOZ_LDAP_SDK
> unset MOZ_LI
> unset MOZ_LITE
> unset MOZ_MEDIUM
> unset NO_SECURITY
> 
> but when I do a
> gmake -f directory/ldapsdk.mk build
> 
> I get the error:
> cd config; gmake
> gmake[1]: Entering directory `/root/mozilla/config'
> gcc -o
> Linux2.2.16_x86_DBG.OBJ/nsinstall.o -c -DXP_UNIX -g -ansi -Wall -pipe -DL
> INUX -Dlinux -DLINUX1_2 -mno-486 -Di386 -D_POSIX_SOURCE -D_BSD_SOURCE -DSW_T
> HREA
> DS -DNEED_ENDIAN_H -DNEED_GETOPT_H -DNEED_IOCTL_H -DUSE_NODL_TABS -DHAVE_SIG
> NED_
> CHAR -DNEED_SYS_TIME_H -DHAVE_SYS_BITYPES_H -DNEED_UINT_T -DNEED_TIME_R -DMI
> TSHM
>  -D_XOPEN_SOURCE -D_PR_LOCAL_THREADS_ONLY -DHAVE_STRERROR  -DDEBUG -UNDEBUG 
> -DDE
> BUG_root -DTRACING -DNSPR20 -DNETSCAPE -DOSTYPE=\"Linux2.2\" -DMOZILLA_CLIEN
> T -D
> LAYERS -DUNIX_LDAP -DNSPR -DMOCHA -DUNIX_ASYNC_DNS -DDEVELOPER_DEBUG   -I../
> incl
> ude   -I/usr/X11R6/include -I../dist/Linux2.2.16_x86_DBG.OBJ/include
> nsinstall
> .c
> cc1: Invalid option `no-486'
> gmake[1]: *** [Linux2.2.16_x86_DBG.OBJ/nsinstall.o] Error 1
> gmake[1]: Leaving directory `/root/mozilla/config'
> gmake: *** [build] Error 2
> 
> 
> Anybody have any suggestions

You might try getting newer SDK bits by checking out from the CVS
branch LDAPCSDK_40_BRANCH.  If that still fails, you may need to find
where -mno-486 is coming from (possible a Linux.mk file somewhere) and 
get rid of it.  I think that support for that flag has been dropped in 
recent versions of gcc.

Dan


-- 

LDAP i18n meeting log posted; minor interface changes upcoming

[Dan Mosedale]

The contents of last week's LDAP internationalization meeting has been 
posted here: .

Additionally, some minor interface changes are coming.  One batch, in
http://bugzilla.mozilla.org/show_bug.cgi?id=70658 removes a number of 
methods that shouldn't really have been public anyway.  Those methods 
are all the non-scriptable ones as well as 
nsILDAPChannel::*PendingOperation().  These methods were already all 
commented in the IDL as being for internal use only, so I don't expect 
anyone will be using them.

http://bugzilla.mozilla.org/show_bug.cgi?id=71247 is a bug I just filed 
to replace all the XPIDL string stuff in the LDAP XPCOM SDK with 
wstrings so that there's no dataloss during character conversion.

Dan

Re: ldap autocompletion impl details (was Re: posting irc meeting log)

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> >> >> /**
> >> >>  * List of defined match items types
> >> >>  *
> >> >>  */
> >> >> const long matchItemsOneOrMore  = 0;
> >> >> const long matchItemsAll= 1;
> >> >>
> >> >
> >> >Would it be worthwhile to design the interfaces to support boolean
> >> >logic (and, or, not, precedence), to allow for future expansion?
> >
> >I'm still curious to hear any thoughts you might have on the above
> >question.
> >
> 
>   Still thinking on it!
>   
>   Example:
>   
>   (name == "X" && nickname == "Y") ||
>   (email 'contains' "ZSxsxZ" || !(fax="123"))
>   
>   Note sure how to do it beyond creating interfaces to
>   cater for statements and operators i.e. defining
>   a binary tree representing the statement where the
>   nodes are operations. Not sure i am using the correct
>   terminology but you see these types of things
>   when looking at compiler books, if one feels
>   so inclined, when referring to parsing statements.

I think the term you're looking for is "expression" rather than
statement.  And yeah, a binary tree sounds like just the right
representation.


>   Hmm... i see what you are saying though.
>   
>   How about a statement interface (which is just
>   a type with no methods) and a simple statement
>   interface which inherits from this.
>   
>   interface Statement : nsISupports
>   {
>   };
>
>   interface SimpleAndOrStatement: Statement
>   {
>   attribute nsISupportsArray matchItems;
>   attribute long matchItemsType;
>   };
>   
>   The nsIAbDirectoryQueryArguments will then
>   contain a statement attribute.
>   
>   Further inheritance from statement could then
>   define unary & binary boolean operations which
>   contain statement attributes. A leaf statement
>   will be a match item.

I definitely like the idea of having the simple case right now and
then leaving it open for expansion.  Hmm, I bet there's some easy way
to specify all the operators as bits of JS code to take advantage of
the fact that JS has full builtin boolean logic already.

> >>Attached is a version with support for nsISupportsArray
> >>and arrays. Additionally added an nsISupports attribute
> >>to the QueryPropertyValue interface if a property
> >>is associated with an interface (e.g. nsIAbCard).
> >
> >Cool; it would be interesting to hear any comments on these from
> >Candice or Ducarroz...
> >
> 
>   Attached is a synchronous implementation of the existing
>   query interfaces which does a linear search over
>   the address books, just like auto completion.
>   (Sorry no comments i hammered it out yesterday
>   real fast).
>   
>   The class nsAbDirectoryQueryAutoComplete performs
>   a query using the same parameters as that for
>   the auto complete, see the method:
>   
>   nsAbDirectoryQueryAutoComplete::Start
>   
>   The example uses a value of 'paul' for all the
>   match items. 3 query results are returned
>   (see the moz.gif image for the list of cards
>and the moz.txt file for the output from
>the query listener).
> 
>   The only thing which is missing is case insensitive
>   matching, thus i think an extra boolean attribute
>   is required on the match item interface.

Cool.  Unfortunately, I don't yet have my head entirely wrapped around 
what you're doing (not enough hours in the day :-/ ), so I don't have
much in the way of comments.  But it seems like a good direction to
me...

Dan

-- 

Re: LDAP i18n meeting log posted; minor interface changes upcoming

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> 
> >The contents of last week's LDAP internationalization meeting has been 
> >posted here: .
> >
> 
>   From the latest IRC chat there was a question about pab storage:
>   
> " Do you know if the Mozilla AdBook pab currently stores in
>  UTF-8 or in Unicode (which would be UCS-2 or UTF016)?"
> 
>   More specifically the mork client implementation converts
>   wstring attributes into utf8 strings which are
>   then stored:
>   
> http://lxr.mozilla.org/seamonkey/source/mailnews/addrbook/src/nsAddrDatabase.cpp
> #1236 
> 
> 
>   It is the same for the preferences:
>   
> http://lxr.mozilla.org/seamonkey/source/mailnews/addrbook/src/nsDirPrefs.cpp#217
> 9 
>   

That sounds like it is consistent with Momoi's statement about
UTF16/UCS2 (aka PRUnichar * / wstring) being used in interfaces, but
UTF8 being used as the preferred storage mode for Unicode.

>   What does this imply for full i18n support?

I think that once we convert the LDAP XPCOM SDK to wstrings, we'll be
in good shape, at least with regards to LDAPv3 servers that are
following the standard by having their data in UTF8.

>   When converting from/to unicode is any data lossed?
>   or are unicode characters encoded into the UTF string.

When you say "unicode", I assume you mean wstring (UTF16/UCS2)
format.  UTF8 is also a unicode encoding.  As I understand it, UTF8
<-> UTF16/UCS2 encoding is lossless.

Dan
-- 

Re: ldap autocompletion impl details (was Re: posting irc meeting log)

[Dan Mosedale]

[EMAIL PROTECTED] (Josh Harding) writes:
> Dan Mosedale wrote:
> > 
> > Paul Sandoz <[EMAIL PROTECTED]> writes:
> > >
> > >   Example:
> > >
> > >   (name == "X" && nickname == "Y") ||
> > >   (email 'contains' "ZSxsxZ" || !(fax="123"))
> > >
> > >   Note sure how to do it beyond creating interfaces to
> > >   cater for statements and operators i.e. defining
> > >   a binary tree representing the statement where the
> > >   nodes are operations. Not sure i am using the correct
> > >   terminology but you see these types of things
> > >   when looking at compiler books, if one feels
> > >   so inclined, when referring to parsing statements.
> > 
> > I think the term you're looking for is "expression" rather than
> > statement.  And yeah, a binary tree sounds like just the right
> > representation.
> 
> This would be a wonderful improvement.  So each leaf node would be a
> condition (i.e. a field name and a value), and each non-leaf node would
> be an operator (e.g. AND or OR).  So far, this sounds good.  Now how
> about adding operators like XOR.  I could see that working, but in
> practice, XOR probably wouldn't be so useful... rather you might want a
> custom operator that says "return True iff exactly one of an entire
> group of conditions is true".  I don't think it would be possible to
> implement this type of operator using a strictly binary tree... it would
> need to be a tree structure that allows for more than two child
> nodes. 

Good point.  Lisp's operator functions work this way.

> This would also make the internal representation more similar to the way
> it would be displayed in the GUI (where a binary tree would require a
> slightly different internal representation).  If I'm not clear on this
> point, I can write up an example.

It would be interesting to see any GUI ideas you have.

To be clear, though, we're talking about searching in addressbooks at
this point, not mail filters.  And it seems likely that this isn't
worth worrying about UI for, at least initially, since I suspect that
only real power-users (or other clients of the directory search code)
are going to need or want to do sophisticated addressbook searches.

Dan
-- 

Re: ldap autocompletion impl details (was Re: posting irc meeting log)

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> 
>   I think i have got it:
>   
>   It is possible to extend expression types to include
>   an N peer boolean expression that contains a list of
>   expressions and applies the same operator to each.
>   
>   Like a 'flatened' part of a binary tree:
>   'if (a | b | c | d)' instead of 'if (a | (b | (c | d)))'
> 
>   (There are probably logical precedence rules to automatically
>   work out this sort of thing from a binary tree and group
>   leaf nodes. I bet its a one liner is lisp!).

Heh.  Yup.  :-)

>   Attached is some idl, does this 'express' a boolean
>   expression model for the GUI use cases you and
>   Matthew have 'expressed'?

Nice work!

Dan
-- 

Re: ldap autocompletion impl details (was Re: posting irc meeting log)

[Dan Mosedale]

[EMAIL PROTECTED] (Josh Harding) writes:
> Paul Sandoz wrote:
> > It is possible to extend expression types to include
> > an N peer boolean expression that contains a list of
> > expressions and applies the same operator to each.
> > 
> > Like a 'flatened' part of a binary tree:
> > 'if (a | b | c | d)' instead of 'if (a | (b | (c | d)))'
> > 
> > (There are probably logical precedence rules to automatically
> > work out this sort of thing from a binary tree and group
> > leaf nodes. I bet its a one liner is lisp!).
> > 
> > Attached is some idl, does this 'express' a boolean
> > expression model for the GUI use cases you and
> > Matthew have 'expressed'?
> 
> That looks good to me.  Just to see if I understand... would the unary
> node type be used for the leaf nodes in the tree?  where you'd have a
> field name, a condition and a value?  e.g.("Sender", "contains",
> "spambot")   Since you have an NPeer node, isn't the Binary node just a
> special case of that?  Would it make things simpler to not have a Binary
> node type and just use Unary and NPeer?  Or maybe I'm overlooking
> something.

No, unary is for operators that only take one operand (eg NOT).  In fact,
not only is Binary not strictly necessary because it's a special case
of NPeer, Unary isn't really necessary either, for the same reason.

Dan


-- 

Re: ldap autocompletion impl details (was Re: posting irc meeting log)

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
>   
>   Attached is the latest query stuff with boolean
>   stuff combined. The existing directory query
>   not inherits from the nsIBooleanExpression interface
>   and the nsIAbDirectoryQueryArguments has a
>   nsIBooleanExpression attribute.

Why have nsIBooleanExpression and nsIBooleanCondition as empty
interfaces, rather than just passing an nsISupports there?

>   I have been thinking about implementing asynchronous
>   query for LDAP (personal and organsizational), just
>   got to read up on LDAP filters so i can correctly
>   generate from the simple boolean expression.

I've been sorting out the best way to parameterize the autocomplete
code, and I suspect it'll be with filters as well.  Maybe we need an
nsIFilter object.

Dan
-- 

Re: 0.8.1?

[Dan Mosedale]

> > Hi all
> > 
> > Will LDAP addressbook be included into 0.8.1? The branch is created
> > yesterday - so now it should be possible to say exactly...
> > 
> > Thanks for any comments.

Much of the LDAP autocomplete work missed 0.8.1 as well, but we should 
be able to hit 0.9.

Dan
-- 

Re: LDAP UI spec:questions answered

[Dan Mosedale]

[Added mozilla-directory and -mail-news to the CC list, as folks there 
are likely to have useful input]

> Jennifer Glick wrote:
> 
>> Hi Srilatha,
>> 
>> Per Product Management's request, I also did a third spec which has 
>> the Address Book settings Global and the LDAP settings Per Account.  
>> I see some potential problems with this design as noted in the spec 
>> though.   The engineering managers and product managers will need to 
>> decide which spec we go with.
>> 
>> http://www.mozilla.org/mailnews/specs/addressbook/LDAP3.html
>> 

My take on the three different specs (the other two of which can be 
found at /LDAP.html and /LDAP2.html) follows:

general
--
* I'd suggest changing  "Sub" and "One" to the slightly less technical 
"One-level", and "Sub-tree".

* I'd propose Base DN instead of Search Root.  My suspicion is that this 
is the parlance that everyone who will be touching this field will be 
familiar with.

LDAP.html
-
* of the two "Global Preferences" options, the second looks both cleaner 
and more function to me

* there doesn't appear to be a spec for the "Advanced" pane

LDAP2.html
--
* In general, I like this one the best.  It seems the most consistent 
with the way the rest of the UI as well as the most functional.


LDAP3.html
--
* options 1 and 2 seem like non-starters, since the LDAP directory that 
you complete against is distinctly not a property of the mail / news 
server in question.  option 3 seems good, though.

Dan




>> 
>> 

Re: LDAP asynchronous calls

[Dan Mosedale]

"Sushmita Roy" <[EMAIL PROTECTED]> writes:
> Hi
> I want to use the Netscape LDAP sdk (on Linux) to perform asynchronous
> search operations. Are there any known problems in using asynchronous
> function calls of the LDAP sdk in a multithreaded environment on Linux.
> Regards

They're being used in the Mozilla code without any noticable issues so
far.

Dan



-- 

Re: LDAP UI spec:questions answered

[Dan Mosedale]

And there's a fourth contender for addressbook preferences UI:

http://www.mozilla.org/mailnews/specs/addressbook/LDAP4.html

There's a meeting tommorrow (Thursday, Mar 22) at Netscape at 1:00 PM
PDT (21:00 UTC) to try and sort all this out.  I've asked for a dialin
number to be set up so that interested parties can join us.  I'll post 
details when I get them.

Dan

-- 

Re: LDAP UI spec:questions answered

[Dan Mosedale]

[EMAIL PROTECTED] (Dan Mosedale) writes:
> And there's a fourth contender for addressbook preferences UI:
> 
> http://www.mozilla.org/mailnews/specs/addressbook/LDAP4.html
> 
> There's a meeting tommorrow (Thursday, Mar 22) at Netscape at 1:00 PM
> PDT (21:00 UTC) to try and sort all this out.  I've asked for a dialin
> number to be set up so that interested parties can join us.  I'll post 
> details when I get them.
> 
> Dan

The MeetingPlace call-in number for this:

Local: 703-265-4963
Toll free: 1-877-319-3725

Scheduled Meeting ID: 532784

Dan
-- 

Re: Error building LDAP C SDK 4.11 (was "Source code...")

[Dan Mosedale]

[EMAIL PROTECTED] (Harshdeep S Jawanda) writes:
> Hi,
> 
> "Michael F. March" wrote:
> 
> > "To get LDAP C SDK 4.0 code (you've got version 3.x), instead \
> >  of using the CVS date tag specified on that page, check out using\
> >  the "-r LDAPCSDK_40_BRANCH" switch to CVS."
> 
> Thanks. I used "LDAPCSDK_41_BRANCH" to get the source code. So far, so
> good.

I would suggest reverting from the 4.1 branch to the 4.0 branch.  I
don't believe the 4.1 branch ever built correctly.

Note that if you're feeling particularly adventurous, the 5.0 SDK has
now landed on mozilla.org (thanks to Michael Hein
<[EMAIL PROTECTED]>).  The branch name is ldapcsdk_branch_50 (this
branch i not guaranteed to be stable).  Note that the new build system
for the 5.0 branch is still only lightly tested, and only on some
platforms at that.

Dan
-- 

Re: Asyncronous calls

[Dan Mosedale]

"Devendra Badhani" <[EMAIL PROTECTED]> writes:
> I'm working on a project where the thruoughput requirement for the LDAP
> search is very high( ~100 results per second). To achive this I thought of
> using
> asynchronus LDAP API.
>Just to get a fair idea of what's going behind the scene and to
> understand the underlying socket implementation I went through the source
> code for the SDK. I am not very clear as to how is the MAPPING between a
> request ( LDAPRequest) and the corresponding socket is maintained. Hence the
> following query :
> - Does it create a new socket for every search? If no then how does it map
> the incoming result packets to the search requests?

No. Each result packet comes with an identifier that the C SDK uses to 
match it to the request.

> - Is there any place where I can get the detailed design of the SDK?

http://docs.iplanet.com/docs/manuals/directory.html#SDKC

Dan

-- 

Re: ldap autocompletion impl details (was Re: posting irc meeting log)

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> >>Attached is the latest query stuff with boolean
> >>stuff combined. The existing directory query
> >>not inherits from the nsIBooleanExpression interface
> >>and the nsIAbDirectoryQueryArguments has a
> >>nsIBooleanExpression attribute.
> >
> >Why have nsIBooleanExpression and nsIBooleanCondition as empty
> >interfaces, rather than just passing an nsISupports there?
> >
> 
>   I guess i wanted to be explicit about the 
>   relationships between expression, condition
>   and operation.
>   
>   Also the nsIAbDirectoryQueryArguments 'expression'
>   attribute is explicit about what type it is.
>   
>   Do you think this is design overkill?
>   i.e. document clearly instead.

I guess I'd vote for the documentation choice, rather than adding
extra interfaces, since those aren't completely free.

> >>I have been thinking about implementing asynchronous
> >>query for LDAP (personal and organsizational), just
> >>got to read up on LDAP filters so i can correctly
> >>generate from the simple boolean expression.
> >
> >I've been sorting out the best way to parameterize the autocomplete
> >code, and I suspect it'll be with filters as well.  Maybe we need an
> >nsIFilter object.
> >
> 
>   Hmmm... do you mean an nsILDAPFilter object?
>   
>   Not sure how this would be different from a
>   boolean expression tree i.e. an LDAP filter
>   string (RFC 2254) can be generated from the
>   expression, unless of course this interface
>   will perform this conversion?

Well, my original thinking was of using ldap_create_filter()**
configuration syntax as a way to parameterize the autocomplete stuff
so that a single string would represent both the search filter itself
as well as the format of the autocompletion string.  But now I think I 
was just confused.

** see 

What I'll actually probably do is just go with two separate strings
for this, like was done in 4.x.

>   I think gives the developer flexibilty if
>   ldap attributes can be represetned as strings
>   with helper interfaces which can convert from
>   more abstract representations.

It still may have some value in the future for exactly this reason.

>   In relation to filters and searches:
>   I notice that URL search has been removed from
>   the nsILDAPOperation interface. I think 
>   i remember reading why some time ago but
>   its lost on me now

Because it was just a wrapper for ldap_url_search(), which claims to
be async, but under the covers it's really not.  See
 for details.

>   I think as long as the nsILDAPUrl is fully
>   featured it does not matter because the
>   appropriate parameters for the searchExt
>   method could be obtained from this interface.

Right, this was exactly the thinking here.

Dan
-- 

Re: Organisational and 10^3 address books

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> 
>   Wanted to run by some things i think are required
>   for the Mozilla address book to cater for organisational
>   (LDAP) and '10K' address books i.e. address books
>   with so many cards it is not feasible to list all cards.
>   
>   o Need attribute that defines if an address book
> is only searchable. This will define organisational
> address books.
> 
> - For 10k address books i think the user needs to
>   define this via a preference which states that
>   the address book should only be searched.

Makes sense. 

> - Is an attribute needed to define type so that
>   associated icons may be displayed?

Type of addressbook?  Or type of card?

>   o GUI Search functionality like netscape 4.X and
> the proposed search functionality that was
> described by Josh Harding and suggested by
> Matthew Thomas.

<[EMAIL PROTECTED]">news://news.mozilla.org/[EMAIL PROTECTED]> is 
what I assume you're referring to.

I agree; this seems like a nice GUI.

> When a searchable address book is selected
> the 'search bar' should be displayed.

I'm not quite sure what you mean by this.

>   o The RDF directory data source needs a query
> command that takes as an argument the search
> critera defined as a boolean expression tree.
> 
> - The data source will be responsible for 
>   for passing the search arguments to the query
>   interface on the RDF directory resource conponent
>   and listening to the results which are then
>   asserted. Thus it is asynchronous in operation.

So if I understand you correctly, this is really an optimization: that
is, a generic helper class could do the entire boolean expression
processing on _any_ RDF datasource.  But this allows datasources which
understand expressions themselves (eg LDAP) to do it much quicker.
Right?

>   The query command should unassert previously
>   returned cards.

Why is this necessary?  Won't the newly created listener not know
about any previously returned cards?

> - A general linear search query component is 
>   available for directories that do not support
>   the query interface. This means that existing
>   local address books may also be searched.

If this only exists to deal with the exist local addressbook, wouldn't 
it make more sense to simply write an instance of the query interface
for the local addressbook that does more clever stuff with
datastructures in order to avoid doing a linear search?  Note that I'm 
completely naive about how mork & the local address book work, so this 
may not be practical.

>   o Offline mode. For organisational address books
> it should be possible to create a local address
> book and copy the cards obtained from the search
> criteria. I don't think a local address book
> needs to be created or modified every time a
> search is performed like 4.X functionality,
> but i am not sure how offline works in general.

I _think_ these were two separate features in 4.x: persistent queries
and replicating addressbooks locally.  I'm not positive about this
though, perhaps someone who knows for sure can pipe up...

>   I think we have moved significantly forward to
>   enable the functionality to support this behaviour.
>   The only area I am unsure about is the GUI bit.

Yeah; I think things are definitely going in the right direction!
What specifically about the GUI are you unsure about?

Dan

-- 

Re: Organisational and 10^3 address books

[Dan Mosedale]

[EMAIL PROTECTED] (Josh Harding) writes:
> Paul Sandoz wrote:
> > 
> > Wanted to run by some things i think are required
> > for the Mozilla address book to cater for organisational
> > (LDAP) and '10K' address books i.e. address books
> > with so many cards it is not feasible to list all cards.
> > 
> > o Need attribute that defines if an address book
> >   is only searchable. This will define organisational
> >   address books.
> 
> Is it possible to query the AB and see how many records are in there
> before attempting to display?  If so, how about a pref (defaulting to
> 10K or whatever) that specifies the MAX_DISPLAY_RECORDS.  If the AB has
> more than that number of records, it's search-only.  This would require
> less interaction by the user.  They don't have to know to set a specific
> AB as search-only... it's done automatically for large ABs, but the
> advanced user still has the option of seeing all records if they really
> want.

In LDAP, anyway, you can't know this without actually doing a query
and hitting the limit.

> > o Offline mode. For organisational address books
> >   it should be possible to create a local address
> >   book and copy the cards obtained from the search
> >   criteria. I don't think a local address book
> >   needs to be created or modified every time a
> >   search is performed like 4.X functionality,
> >   but i am not sure how offline works in general.
> 
> How about this:  After a search is completed (regardless of the source),
> present the user with the option of merging the results into an existing
> AB[1] or adding to a new one:
> 
> [Save these search results to]  [Personal AB:^]
> 
> In the select list, is a list of all local ABs and the keyword .

This sounds cool!

> Scenario:  User selects and AB with >10K records and gets the search
> options.  They perform a search for  contains "@".  Do you stop
> the search after MAX_DISPLAY_RECORDS(see above) are found and present a
> warning?

In LDAP, at least, we probably need to set some minimum limits so that
naive users don't drive the server into the ground with enormous
searches.  Perhaps a minimum search term of at least 2 or 3 characters
would be a good such limit.

> [1]: Merging search results could present other problems.  What do you
> do with duplicate entries?  Options:
> 
> 1) Overwrite the existing entry with the one from the search results.
> 2) Keep the old one and ignore the new one.
> 3) Use data from the new one to fill in blank fields from the old.
> 4) Present the user with a dialog giving them the above options and a
> "use this choice for all remaining conflicts".
> 
> None of those seem real appealing to me.

Probably number 4 is the only one that's really workable.

Dan

-- 

Re: ldap autocompletion impl details (was Re: posting irc meeting log)

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
>   
>   It would be nice if the existing
>   nsILDAPOperation.seatchExt method included the
>   returned attributes parameter as support in the
>   nsILDAPURL interface :-)
>   

Agreed, we could also use this to optimize autocomplete searches.  Can 
you file a bug on this and assign it to [EMAIL PROTECTED] and cc me?

Dan

-- 

Re: Announcement: LDAP C SDK /w NSS 3.2 support on Mozilla

[Dan Mosedale]

Michael Hein <[EMAIL PROTECTED]> writes:
> The 5.0 version of the LDAP C SDK with NSS 3.2/NSPR 4.1 support is now
> fully available as open source on Mozilla.  All future development will
> now take place using the mozilla CVS repository and no further
> development is planned within the iPlanet firewall.  For the time being
> I will be gating putbacks quite closely until we have the "warm fuzzy's"
> w.r.t the quality of the source code we get contributed.  I will be
> working with the eClient folks in the near future to make the LDAP C SDK
> builds more mozilla friendly as they currently are very iPlanet
> specific.  For the time being only the libraries can be built (even
> though all of the source code IS there) as the command line utilities
> needs svrcore (This is planned to be part of NSS 3.3).

This is great news; thanks for all your hard work, Michael!  For those
who are interested, at some point not too long after Mozilla 0.9 we
(the Netscape eClient folks) will start working on switching the
browser build over to using the new C SDK, after which we'll start
investigating LDAP over SSL support in the browser.

Dan

-- 

Re: Organisational and 10^3 address books

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
>   
> >>  When a searchable address book is selected
> >>  the 'search bar' should be displayed.
> >
> >I'm not quite sure what you mean by this.
> >
> 
>   Hmm... that a search tool bar should become
>   visible if not already so, so that a user
>   can enter the search query.

OK, that makes sense.

> >>o The RDF directory data source needs a query
> >>  command that takes as an argument the search
> >>  critera defined as a boolean expression tree.
> >>  
> >>  - The data source will be responsible for 
> >>for passing the search arguments to the query
> >>interface on the RDF directory resource conponent
> >>and listening to the results which are then
> >>asserted. Thus it is asynchronous in operation.
> >
> >So if I understand you correctly, this is really an optimization: that
> >is, a generic helper class could do the entire boolean expression
> >processing on _any_ RDF datasource.  But this allows datasources which
> >understand expressions themselves (eg LDAP) to do it much quicker.
> >Right?
> >
>   
>   I suppose it could, but i do not understand fully
>   what you mean.
>   
>   The 'generic helper' would have to understand one or
>   more of uris, statements and hierarchical relations of
>   on the datasource.

I'm not sure why it needs to understand hierarchical relations.  Can
you clarify?

>   However, i think it could be done quite easily for
>   the js LDAP datasouce because of its search based
>   nature.
>   
>   It is not just an optimization because the query
>   can change the 'normal' hierarchical relationship
>   of an RDF graph. For example it should be possible
>   to do a query on the Address Book Container, this
>   flattens and contracts.

How can a query change the hierarchy in an RDF graph?  I'm really
confused now.  

>   
>   In general it would be interesting if an SQL type
>   query could be performed on an RDF datasources.
>   http://www.intellidimension.com/RDFGateway/gateway.asp
>

That is cool!  On a related tangent :-), someone (whom I've been
derelict in getting review or help for :-( ) has written a mozilla
datasource which talks to a PostgresSQL database.

> >>The query command should unassert previously
> >>returned cards.
> >
> >Why is this necessary?  Won't the newly created listener not know
> >about any previously returned cards?
> >
> 
>   Query 1 returns set A of cards
>   Query 2 returns set B of cards.
>   A n B = 0
>   
>   How does affect an RDF datasource. Is the
>   result of two queries returning sets A and B of
>   cards respectively A u B statements?
>   
>   I don't know enough about this really.

RDF assertions are statements.  As far as I know, if you're listening
to a datasource, you need to parse the assertions you get and see if
they're ones that you care about.  Since multiple queries may be
happening simultaneously, I don't believe you're guaranteed that the
assertions you see are necessarily related to your query.  It sort of
sounds as though you and I are talking about asking the datasource
different types of questions.  I guess I'm assuming that the
datasource object may be shared and will represent the state of the
universe, not private and representing the state of the query.  But
maybe I'm off-base.

> >>  - A general linear search query component is 
> >>available for directories that do not support
> >>the query interface. This means that existing
> >>local address books may also be searched.
> >
> >If this only exists to deal with the exist local addressbook, wouldn't 
> >it make more sense to simply write an instance of the query interface
> >for the local addressbook that does more clever stuff with
> >datastructures in order to avoid doing a linear search?  Note that I'm 
> >completely naive about how mork & the local address book work, so this 
> >may not be practical.
> >
> 
>   Yep that right. I think of it as a helper for
>   directories that have not yet implemented
>   specific query functionality.
>   
>   It would definitely be more efficient to go to
>   the mdb and mork level, but yuck!
>   I am suspect on mork's level of efficiency and
>   unsure of its query capability.

I assume ducarroz would know more about this, since he wrote the
original autocomplete-against-mork code.

>   What would be really cool in a set of data base
>   connection interfaces (like JDBC or SDBC (star open office))
>   and an implementation to MySQL.
>   (interestingly enough people have been talking
>   about an OpenLDAP back end to MySQL, the 
>   implications of which start to make me dizzy with
>   what can be connection to what!)

*chuckle*

Dan

-- 

Re: Organisational and 10^3 address books

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
>
> >>It is not just an optimization because the query
> >>can change the 'normal' hierarchical relationship
> >>of an RDF graph. For example it should be possible
> >>to do a query on the Address Book Container, this
> >>flattens and contracts.
> >
> >How can a query change the hierarchy in an RDF graph?  I'm really
> >confused now.  
> >
> 
>   Hmm... so am i. 
>   
>   A crude example of an RDF graph of address books
>   is shown below:
>   
>   abdirectory://
>   [Child] abmdbdirectory://abook.mab
>   [ChildCard] abmdbcard://abook.mab/Card1
>   [ChildCard] abmdbcard://abook.mab/Card2
>   [ChildCard] abmdbcard://abook.mab/Card3
>   [Child] abmdbdirectory://history.mab
>   [ChildCard] abmdbcard://history.mab/Card1
>   [ChildCard] abmdbcard://history.mab/Card2
>   [ChildCard] abmdbcard://history.mab/Card3
>   
>   
>   A query could result in:
> 
>   abdirectory://
>   [QueryChildCard] abmdbcard://abook.mab/Card1
>   [QueryChildCard] abmdbcard://history.mab/Card3

OK, I think I see what you mean now.  How about this: instead of
having a single set of QueryChildCard attributes on the moz-abdirectory://
URL, I think the right thing to do is to define a way to represent
each query as a URI, and then assert the QueryChildCard properties on
the relevant URI.  This way you can have an arbitrary number of
separate, concurrent searches under the moz-abdirectory:// namespace.
This is exactly the way the LDAP datasource works.  You could
probably even borrow most of your URL syntax from the syntax of LDAP
search URLs (RFC 2255).

Given that writing the code to generate and parse such URIs is
probably a bunch of work, for the time being you could probably just
use opaque URI handles such as:

moz-abdirectory://searches/search-1
moz-abdirectory://searches/search-2
...

Thoughts?

> 
>   I suppose you could consider it an optimization if the
>   abdirectory:// resource performs the query rather than a
>   helper traverses the RDF graph to return the same result.

Yes, that's exactly what I meant.

>   I also like the concept of the Aurora project.
>   This is where generic querying/searching could be
>   very useful. Imagine having a 'virtual folder' which
>   is associated with a query which dynamically updates
>   when new content maching the query is asserted.
>   (e.g. virtual mail folders, or for news casts etc..)

Agreed; this is very cool.  As far as generic use of RDF, some very
interesting stuff to look at is the Dublin Core metadata work.
 Once upon a time, there was a
theory that we should replace the ad-hoc NC-rdf vocabulary used by
much of the browser with something Dublin Core-based, to allow for
better interoperability.  Last time I looked at this, that seemed like 
it might be not terribly practical, because to express a bunch of the
semantics in the NC-rdf vocabulary well would require using the
Qualified Dublin Core, and this adds a non-trivial amount of
complexity.  

> >> >> The query command should unassert previously
> >> >> returned cards.
> >> >
> >> >Why is this necessary?  Won't the newly created listener not know
> >> >about any previously returned cards?
> >> >
> >> 
> >>Query 1 returns set A of cards
> >>Query 2 returns set B of cards.
> >>A n B = 0
> >>
> >>How does affect an RDF datasource. Is the
> >>result of two queries returning sets A and B of
> >>cards respectively A u B statements?
> >>
> >>I don't know enough about this really.
> >
> >RDF assertions are statements.  As far as I know, if you're listening
> >to a datasource, you need to parse the assertions you get and see if
> >they're ones that you care about.  Since multiple queries may be
> >happening simultaneously, I don't believe you're guaranteed that the
> >assertions you see are necessarily related to your query.  It sort of
> >sounds as though you and I are talking about asking the datasource
> >different types of questions.  I guess I'm assuming that the
> >datasource object may be shared and will represent the state of the
> >universe, not private and representing the state of the query.  But
> >maybe I'm off-base.
> >
> 
>   I think understand what you say.
>   
>   I am unsure how the listener who initiated the query
>   relates to the assertions associated with the query
>   results.
>   
>   If there is only one predicate, property, associated with
>   query statements, e.g. 'QueryChild' then it needs to be
>   ensured that these statements are related to the last query
>   on a subject.
>   Multiple queries should not result in a union.

I think the right solution her

Re: Organisational and 10^3 address books

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> 
>   Thanks! I see the light.
>   I was stuck in some precipitous local minima
>   of thought.

Heh; I like this turn of phrase.  :-)

>   Copying somthing similar to ldap filter is
>   a good idea:
>   
>   uri = scheme ":" path [ "?" query ]
>   query   = "(" queryexpression ")"
>   querycomp   = and | or | not | querycondition
>   and = "&" queryexpression
>   or  = "|" queryexpression
>   not = "!" query
>   queryexpression = 1*query
>   querycondition  = attr "," condition "," value
>   condition   = equal | notequal |
> lessthan | greaterthan |
> beginswith | endswith |
> contains | doesnotcontain |
> soundslike | regex |
>   equal   = "="
>   notequal= "!="
>   lessthan= "lt"
>   greaterthan = "gt"
>   beginswith  = "bw"
>   endswith= "ew"
>   contains= "c"
>   doesnotcontain  = "!c"
>   soundslike  = "~="
>   regex   = "regex" 
>   attr= *(alphanum | escaped)
>   value   = *(alphanum | escaped)
>   escaped = from RFC 2396
>   alphanum= from RFC 2396
>   
>   This conforms to RFC 2396.

At first read, it looks good to me.

>   Should be 'reasonably' easy to parse so 
>   i think i can do it fairly quickly.

Cool!

>   There may be value in having a Dublin Core data
>   source which could read DC meta data values from
>   HTML data.

Yeah, if the Dublin Core starts to really catch on, it
would be nice to be able to drive XUL templates using it
automatically.

Dan
-- 

Re: Organisational and 10^3 address books

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> 
>   I modified the query string spec to use
>   'and', 'or' and 'not' instead of the symbols
>   because the '|' is not a recommended character
>   in the URI spec.

Makes sense.  

>   Last week i got Org LDAP entries into the
>   address book using the query string. Given
>   some minor code modifications it should
>   also work for the MDB and MAPI implementations,
>   so it should be possible to search all types
>   of address book via a search GUI.

Wow; fantastic!

>   I had to change the directory data source to
>   use synchronous proxy observers just like the js
>   LDAP data source so it can be really slow.

I don't really understand why the JS datasource uses sync proxies
(peterv?).  Given that this is really a callback, and there's no
interesting way to recover from an error in a callback, it seems
like async (fire & forget) would be fine.  On the other hand, using
async proxies is probably more likely to subject us to event queue
flooding if there are a lot of entries (like bug 50104).  Anyone, you
could conceivably try switching one or both of these proxies to being
async and see whether things get better or worse.

>   Getting 100 address book entries is about 5x slower
>   using a debug mozilla build than 4.x,
>    but it works!

This is great!  It'll be interesting to see how much faster this is on 
a release build.

>   Now have to get a GUI working which appends a
>   generated query string to the currently selected
>   address book before the child cards are obtained...
>
>   Attached is the Mozilla card to LDAP attribute
>   mapping that is currenly used. This is based on
>   the LDIF conversion code.
>   At some point it might be advantageous to have
>   a mapping table in the preferences, or changes to
>   the default. I presume this would be required by
>   some enterprise clients?

Yeah, I would think so.  We could either have preferences override
individual values like 4.5 (see

http://docs.iplanet.com/docs/manuals/communicator/ldap45.htm#customizing-attribute-names
 

for details) or just have a single preference that overrides the file
the table is read from.  The former might be preferable, since it
would probably play more nicely with preferences locking stuff.  I've
CCed the prefs newsgroup in case any of the experts in that area have
comments on this.  Conceivably both options could be used together.

> 
> /*
>   Table defining the relationship between
>   mozilla card properties and corresponding
>   ldap properties.
> 
>   Multiple entries for a mozilla property define
>   there is a many to one relationship between
>   ldap properties and the mozilla counterpart.
> 
>   There is a one to one relationship between
>   a mozilla property and the ldap counterpart.
>   If there are multiple entries for a mozilla
>   property the first takes precedence.

What if there are multiple entries for an LDAP property?  I don't
_think_ LDAP guarantees that they will be returned in a predictable
order, though I could be wrong.

>   This ensures that
>   
>   1) Generality is maintained when mapping from
>  ldap properties to mozilla.
>   2) Consistent round tripping when editing 
>  mozilla properties which are stored on
>  an ldap server
> */

It would be cool to have comments in the table describing the origin
(ie objectClass) where each of those attributes come from.  I suspect
most of them are from inetOrgPerson, but there's definitely a few that 
aren't.

> MozillaLdapPropertyRelation mozillaLdapPropertyTable[] =
> {
>   {MozillaProperty_String, "FirstName",   "givenname"},
>   {MozillaProperty_String, "LastName","sn"},
>   {MozillaProperty_String, "LastName","surname"},
>   {MozillaProperty_String, "DisplayName", "cn"},
>   {MozillaProperty_String, "DisplayName", "commonname"},
>   {MozillaProperty_String, "DisplayName", "displayname"},
>   {MozillaProperty_String, "NickName","xmozillanickname"},
>   {MozillaProperty_String, "PrimaryEmail","mail"},
>   {MozillaProperty_String, "SecondEmail", "xmozillasecondemail"},
>   {MozillaProperty_String, "WorkPhone",   "telephonenumber"},
>   {MozillaProperty_String, "HomePhone",   "homephone"},
>   {MozillaProperty_String, "FaxNumber",   "fax"},
>   {MozillaProperty_String, "FaxNumber",   "facsimiletelephonenumber"},
>   {MozillaProperty_String, "PagerNumber", "pager"},
>   {MozillaProperty_String, "PagerNumber", "pagerphone"},
>   {MozillaProperty_String, "CellularNumber",  "mobile"},
>   {MozillaProperty_String, "CellularNumber",  "cellphone"},
>   {MozillaProperty

Re: Address-book refactoring

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> 
> >Er... I heard there was some address book refactoring going on, so I
> >thought I'd float this idea.
> >
> >Why do address book entries not have a field for "Encryption key" and a
> >preference "automatically encrypt mail to this user" (enabled only when
> >we've got plug-in crypto from e.g.
> >http://bugzilla.mozilla.org/show_bug.cgi?id=22687 or (later) S/MIME.) This
> >would make it an order-of-magnitude easier for crypto to become the norm
> >rather than the exception for email, and make the world a more secure
> >place.
> 
>   I agree, i like the idea.
>
>   I can add another attribute to the nsIAbCard
>   interface, 'encryptionKey', even if its not
>   implemented yet its better to change the interface
>   now, if it makes sense to others on mail-news.
>   (i am involved in the group that is refactoring
>the address book).
>   
>   My knowledge of crypto stuff is limited, but I
>   presume the key data type is just a string?
>   

My understanding is that there are already at least two widely-used
attributes for storing S/MIME keys in LDAP (there should really only
be one, but that's another story).  It would be interesting to know if
there is any similar for PGP keys.  I think that in the case of S/MIME
keys, at least, storing them in the addressbook would need to somehow
be linked with the public key database (key*.db?).  Adding the .crypto
group here so that more knowledgable folks can chime in.

>   It would also,  just got me thinking!, be useful
>   to have a URI pointing to a user's calendar for
>   integration with future calendaring support.

I agree; that would be handy as well.  Adding the .calendar newsgroup
to see if anyone there has thoughts.

Dan
-- 

Re: Address book functionality, proposed putback 2.

[Dan Mosedale]

John Marmion <[EMAIL PROTECTED]> writes:
> Now that our first patch on re-factoring the Address Book 
> code is nearing its landing date, I thought it might be 
> appropriate to highlight what is coming in our second 
> patch and also to ask some questions. I am forwarding a 
> summary of the functionality of this patch first sent to 
> the mozilla mailnews group on the 22nd March by Paul Sandoz. 
> 
> 1. The patch will contain an LDAP implementation. To avail
> of this we will need to link against the ldap C-SDK.
> Should the mozilla build of this now need to be enabled by
> default to support this? Who do we contact to  make that 
> decision?

In fact, that's already happened.  Sorry I was too lame to post
announcing it here.  The LDAP XPCOM SDK and C SDK are turned on in
in the default trunk builds

> 2. In adding MAPI and LDAP support, should we be looking
> at restructuring the build to create separate shared libs 
> to allow inclusion/exclusion for MAPI support and/or LDAP 
> rather than using #ifdef as e.g. MAPI is windows only rather
> than the existing single shared address book library.

Well, there has been talk about making LDAP capabilities downloadable
and installable as a separate XPI so the people who don't need LDAP
capabilities don't have to get it.  This seems like it would be worthwhile
and would imply a separate shared library for that.

I'm not sure about MAPI, though.

> 3. Will the preference stuff curreently being worked on by Dan 
> & Srilatha & Co. get into 0.9 milestone (18th April). We will 
> want to tie into this the next time around.

Yes, we're working like mad to make that happen.

> 4. The next patch will not change the interfaces as the previous
> one did thereby resulting in knock on effects to AIM. There will
> be a change to one implementation which AIM uses. And now that we 
> are more aware of the mozilla processes, can we envisage a shorter
> time to get this patch into the tree. What is the best possible
> milestone to be targetted if we get the patch to you by the
> end of this week?

Candice & Scott will have to field this one.  :-)

Dan
-- 

Re: Organisational and 10^3 address books

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> 
> >>I had to change the directory data source to
> >>use synchronous proxy observers just like the js
> >>LDAP data source so it can be really slow.
> >
> >I don't really understand why the JS datasource uses sync proxies
> >(peterv?).  Given that this is really a callback, and there's no
> >interesting way to recover from an error in a callback, it seems
> >like async (fire & forget) would be fine.  On the other hand, using
> >async proxies is probably more likely to subject us to event queue
> >flooding if there are a lot of entries (like bug 50104).  Anyone, you
> >could conceivably try switching one or both of these proxies to being
> >async and see whether things get better or worse.
> >
> 
>   If you use async then the GUI becomes very sluggish
>   in debug, not sure what its like in release, as per
>   bug 50104.
>   
>   I am testing against an internal LDAP server which
>   contains all Sun employee info, so it is very
>   responsive.

OK, that makes sense.  You might want to try apply danm's patch in
50104 with async proxies and see if it makes any difference.  Either
way, if you could comment in the bug that'd be great... because we
really should apply pressure to get 50104 fixed, if at all possible.

>   Also modified the ds so that non proxy RDF observers
>   are used for synchronous address books.
>   I do this by checking if the current thread
>   is equal to the main thread (which is the
>   UI thread):
>   
>   nsCOMPtr currentThread;
>   rv = nsIThread::GetCurrent (getter_AddRefs(currentThread));
>   NS_ENSURE_SUCCESS (rv, rv);
>   nsCOMPtr uiThread;
>   rv = nsIThread::GetMainThread (getter_AddRefs(uiThread));
>   NS_ENSURE_SUCCESS (rv, rv);
>   
>   nsCOMPtr observers;
>   if (currentThread == uiThread)
>   {
>   }
>   else
>   {
>   }
>   
>   I presume this will be OK in the future.
>   i.e. the ui thread will always be the main
>   thread...

That seems pretty likely to me, though I'm not entirely sure how we could 
verify that assumption.  Maybe ask in .xpcom and/or .xpfe?

Dan
-- 

Re: Address book functionality, proposed putback 2.

[Dan Mosedale]

Dan Mosedale <[EMAIL PROTECTED]> writes:
> John Marmion <[EMAIL PROTECTED]> writes:
> > Now that our first patch on re-factoring the Address Book 
> > code is nearing its landing date, I thought it might be 
> > appropriate to highlight what is coming in our second 
> > patch and also to ask some questions. I am forwarding a 
> > summary of the functionality of this patch first sent to 
> > the mozilla mailnews group on the 22nd March by Paul Sandoz. 
> > 
> > 1. The patch will contain an LDAP implementation. To avail
> > of this we will need to link against the ldap C-SDK.
> > Should the mozilla build of this now need to be enabled by
> > default to support this? Who do we contact to  make that 
> > decision?
> 
> In fact, that's already happened.  Sorry I was too lame to post
> announcing it here.  The LDAP XPCOM SDK and C SDK are turned on in
> in the default trunk builds

But I forgot to mention that RDF datasource is not yet reviewed,
superreviewed, or turned on.  I assume you are gonna need it for your
second landing, correct?

Dan
-- 

Re: LDAP attribute preferences Re: Organisational and 10^3 address books

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> 
> >>Attached is the Mozilla card to LDAP attribute
> >>mapping that is currenly used. This is based on
> >>the LDIF conversion code.
> >>At some point it might be advantageous to have
> >>a mapping table in the preferences, or changes to
> >>the default. I presume this would be required by
> >>some enterprise clients?
> >
> >Yeah, I would think so.  We could either have preferences override
> >individual values like 4.5 (see
> >
> 
>>http://docs.iplanet.com/docs/manuals/communicator/ldap45.htm#customizing-attribute-names
> 
> >
> >for details) or just have a single preference that overrides the file
> >the table is read from.  The former might be preferable, since it
> >would probably play more nicely with preferences locking stuff.  I've
> >CCed the prefs newsgroup in case any of the experts in that area have
> >comments on this.  Conceivably both options could be used together.
> >
> 
>   I like the idea of relating ldap attributes to
>   ldap attributes and fixing the relationship between
>   Mozilla card properties and ldap attributes.

This seems like a good idea.  But isn't it orthogonal to the above 
question of how we connect it to the preferences?  I'd be interested
in hearing if any of the prefs & prefs locking folks have any opinions 
on this...

> >> /*
> >>Table defining the relationship between
> >>mozilla card properties and corresponding
> >>ldap properties.
> >> 
> >>Multiple entries for a mozilla property define
> >>there is a many to one relationship between
> >>ldap properties and the mozilla counterpart.
> >> 
> >>There is a one to one relationship between
> >>a mozilla property and the ldap counterpart.
> >>If there are multiple entries for a mozilla
> >>property the first takes precedence.
> >
> >What if there are multiple entries for an LDAP property?  I don't
> >_think_ LDAP guarantees that they will be returned in a predictable
> >order, though I could be wrong.
> >
>   
>   Currently there is no provision for managing multiple
>   entries, the first one wins. I was not sure how to
>   deal multiple entries...

I just asked Leif about this, and he said that the protocol does not
guarantee a predictable order, though the current versions of the
Netscape/iPlanet directory server happen to return them in the same
order every time.  I'm not real sure what could be done about this
either, other than making the address book code support multi-valued
properties like LDAP does.  I'm not also sure what the UI and code
implications of this are (ie whether it's really practical).  But it
would probably solve Gerv's multiple email address problem.

> >It would be cool to have comments in the table describing the origin
> >(ie objectClass) where each of those attributes come from.  I suspect
> >most of them are from inetOrgPerson, but there's definitely a few that 
> >aren't.
> >
> 
>   Yep, most are inetOrg or from the super classes.
>   I will update.

Great!

Dan
-- 

Re: Organisational and 10^3 address books

[Dan Mosedale]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> >>If you use async then the GUI becomes very sluggish
> >>in debug, not sure what its like in release, as per
> >>bug 50104.
> >>
> >>I am testing against an internal LDAP server which
> >>contains all Sun employee info, so it is very
> >>responsive.
> >
> >OK, that makes sense.  You might want to try apply danm's patch in
> >50104 with async proxies and see if it makes any difference.  Either
> >way, if you could comment in the bug that'd be great... because we
> >really should apply pressure to get 50104 fixed, if at all possible.
> >
> 
>   Done.

Great; thanks!

>   I am curious to see how things behave in a release
>   build. I am gonna kick one off and see what
>   happens.

Cool...

>   One thing i pointed out in bug 50104 is the fact that
>   asynchronous RDF datasources may be tied to the UI
>   thread for notification. Observers other than XUL
>   may not care that the notifications occur on a
>   different thread. Thus the address directory datasource
>   aan the js LDAP datasource are in some sense bound to
>   the UI thread.
>   If it was up to the XUL Observers to decide how to
>   process the events then there may be scope for
>   optimization, via the choice of a special event
>   queue and proxying of i.e. move the responsibility
>   away from the datasource.

Hmmm, that's a good point.  The way LDAP XPCOM SDK deals with this is
that it just makes you pass in an object which implements an
nsILDAPMessageListener as a callback, and if the caller needs to
ensure that the callback happens on some particular thread, then the
caller passes in a proxied callback object.  Perhaps RDF and it's
callers (including XUL) could be made to work this way as well.  It
would presumably require one tree whomp, but shouldn't be very hard.
Adding .rdf and .xpfe to see what the owners of those modules think...

Dan
-- 

Re: LDAP & MAPI Address Book Experimental Builds

[Dan Mosedale]

John Marmion <[EMAIL PROTECTED]> writes:
>
> Some of you may be aware of our attempt here to add 
> Multiple Address Book support to Mozilla. Our first
> patch landed successfully for milestone 0.9. This 
> refactored the address book source to support multiple 
> address books. Our next patch will add LDAP and MAPI/Outlook
> support plus an enhanced ldap query string support. We 
> are making some experimental builds available of this Patch II 
> at the following website:
> 
> http://www.angelfire.com/linux/mozaddr
> 
> Linux and Windows builds are there now. We will be attempting 
> to get Patch II put back to the tree.

This is great!  I just tried the linux build this afternoon and was
able to make it play reasonably nicely with AOL T/W's internal
directory server.  I'd be interested in helping you land this in the
Mozilla tree, but this would be a lot easier if we could get
the patches in question in Bugzilla.  

I'd suggest creating a new tracking bug in Mail/News : Addressbook for
the various different features of this patch, and if you'd like me to
eventually do the checkin honors, go ahead and assign it to me.  The
next step would be to file multiple bugs for the various
sub-components; and attach the patches to those bugs.  At a minimum:

* one bug for the modifications to the existing addrbook code 

* one bug for the LDAP searching code (we could probably just use
17879 for this)

* one bug for the MAPI searching code

All three of these bugs should block the main tracking bug.  Splitting
it up like this will make it much easier to get through the review
process and will evoke less fear when it starts being tracked on the
mozilla planning radar .

If this sounds like a plan you'd like to go forward with, I'll deal
with the landing radar tommorrow.

Speaking of bugs, is 69480 actually just left over from the
addressbook refactoring landing and should be resolved?

> There is an explanation of how to enable both LDAP and
> MAPI by simply editing the prefs.js file in the text file 
> SummaryPatchII.txt. Our next Patch (Patch III)
> will enable this through the GUI. We hope to post some
> screen shots of this soon.

Very cool; nice work!

> We would encourage people to download and get back to us 
> with any issues.

One problem I noticed was that if I only used a single search term,
rather than an or'ed pair of search terms as used in the example, I
didn't see any results.  I don't have the details near me at the
moment, unfortunately, but I'll look again when I do.

Dan
-- 

Re: LDAP logging?

[Dan Mosedale]

Henrik Gemal <[EMAIL PROTECTED]> writes:
> I'm trying to get LDAP working from my compose window but it doesn't
> seems to work. I'm using the zip version of the mozlla win32 build.
> Should ldap work there?
> 
> Now I'm trying to log the LDAP commands via:
> 
> SET NSPR_LOG_MODULES =
> IMAP:5,POP3:5,NNTP:5,SMTP:5,ldap:5
> 
> but it doesn't seem to log any ldap commands. Is it possible to log ldap
> this way?
> Logging of IMAP, etc works just fine.

I have my NSPR_LOG_MODULES set like this:

NSPR_LOG_MODULES=sync,ldap:5,ldapautocomplete:5

This will get you a fair amount of logging, though it's not yet as
extensive as it should be.

Dan
-- 

Re:

[Dan Mosedale]

Binary Runner wrote:

> Hi,
>
> I've looked again at the LDAP RDF datasource and outliner and found some fact I'd 
>like you correct if they're wrong:
>
I'm ccing peterv and a couple of mozilla newsgroups on this reply, as I 
think this is of general interest.  Hope that's ok

> 1/ search uri (like ldap://...??sub) doesn't generate hierarchy,all the entries are 
>placed at the same level that's probably the reason why I was unable to display it as 
>tree
>
>
> 2/ RDF datasource doesn't make the hierarchy from data acquired from the server
>
It's true that the RDF representation of a search URI does not generate 
any hierarchy.   In the datasource, what's specifically being 
represented is a set of assertions about that search URI, not about the 
hierarchy of the server.  That is, the statements being made are of the 
form "This LDAP search URI returns this directory entry".  There's no 
particular hierarchy associated with that.

> 3/ there is no way how to get whole DN of LDAP entry returned,  
>there is no way how to access objectClass hierarchy for
>entry's objectClass,
>
You're right about the DN.  Probably the thing to do is to make the 
datasource support a predicate (arc) for LDAP DN; I suspect this would 
need to live in the NC-rdf namespace, as it may be legal in LDAP to have 
an attribute named "dn". 

I was under the impression that objectClass was just another LDAP 
attribute, as far as searches are concerned.  Is that not the case?

>there is no way how to affect content generation based on matching RDF data against 
>some
>pattern and firing rule only if pattern matches
>
This is what XUL templates are for, I believe.  Can you say more about 
the specific sort of pattern matching that you want to do?

> 4/ If I'm ok in these points it could be good to
>implement container based on recursion level in LDAP tree
>
For the most part, it doesn't really matter whether recursion is 
represented by containers or arcs, I don't think.  I suspect that just 
extending the datasource to support a special arc for DN (and, if 
necessary, one for objectClass) would be sufficient.

Dan

browser builds w/LDAP/MAPI addrbook integration; testers sought

[Dan Mosedale]

[Followups set to .mail-news]

Martin Maher <[EMAIL PROTECTED]> writes:
> There are some experimental builds (windows, linux
> and mac) available on 
> 
> http://mozdev.org/ftp/pub/sun/
> 
> These builds include changes to allow users to
> read both LDAP and MAPI addressbooks from there
> mozilla addressbooks. There is more information
> available in the ftp site above to do this,
> 

There has been a certain amount of traffic in these groups in the past
of folks who were interested in helping test out LDAP functionality in
the builds.  Now would be a great time to help bang on some builds.
We'd hoping to land the changes in these builds in the mozilla tree
when the tree opens for 0.9.2, but we can only do that if we're
confident that they've seen enough testing.  

If folks could check these out and file bugs (especially keeping an
eye out for addressbook-related regressions), that would be very
helpful.  Any bugs filed should be made to block bug 80172, as that's
how we'll be tracking this.

Thanks!
Dan




-- 

Propragating low-level (LDAP) errors to the UI

[Dan Mosedale]

[more newsgroups added; i'm hoping that xpcom and netlib folks will
chime in here]

Paul Sandoz <[EMAIL PROTECTED]> writes:
> >> Perhaps re-using and
> >>creating exception codes and mapping these to 
> >>i18n strings for dialogs to use in the address
> >>book?
> >
> >Sounds good.
> 
>   Just come across this bug:
> 
>   http://bugzilla.mozilla.org/show_bug.cgi?id=13423
>   
>   in relation to the nsIErrorService.idl

I suspect that nsIErrorService will probably be the most straightforward way
to propagate network-level errors up to the UI, since it's designed
for just this purpose.  nsIException support just landed recently
,
so it would also be interesting to hear whether the netlib folks have
any plans to move in that direction, and what the stated XPCOM
direction is...  

> >>Or is there going to be generic listeners on 
> >>ldap sessions/connections which can inform the
> >>user when somthing has gone wrong? so that
> >>specific applications do not need to inform
> >>the user if general ldap operations have failed.
> >
> >I hope you don't suggest to put up error dialogs from the backend? A few 
> >functions in Mailnews do that, and they cause problems when there is no 
> >GUI (as in my Mailnews CORBA wrapper). It's a bug.
> >
> 
>   Gosh no! 
>   
>   I was wondering if it was possible for the mozilla
>   browser to add observers to an ldap 'session manager'
>   such that it could listen to specific events like
>   errors and thus display generic dialogs (if of course
>   the client performing an ldap operation allowed for
>   listening to be enabled perhaps?)
>   Or maybe have a session manager context so that different
>   clients can deal with ldap errors within contexts in a
>   more specific manner.
>   
>   I think it might be easier to extend the address book
>   session interface to handle the registration of error
>   observers. Thus ensuring scriptablity and GUI independence
>   of the address book implemenations.

Well, the LDAP routines all return the errors documented in 
the nsILDAPErrors.idl and nsLDAP.h in directory/xpcom/base/public/.
So I'm a little unclear why a session manager or observer paradigm
would be useful in this context... wouldn't have the calling code and
callback functions check for errors be sufficient?

(Tangent: I think the nsLDAP.h errors should probably be moved to a
%C++ block in nsILDAPErrors.idl).

Dan
-- 

Re: LDAP address book settings

[Dan Mosedale]

[.mail-news added]

[EMAIL PROTECTED] (Csaba Borbola) writes:
> Hi Dan,
> 
> I'm doing the LDAP addressbook settings and I would like to get
> some comment related to filters.
> I think the LDAP address book should not use the filter
> settings from the preferences, which was set for autocompletion.
> It might have a point to merge that filters with the 
> address book filters, but I don't really think we should.
> What is your opinion about it? 
> 
> I would just skip those filters, because we are going to use
> the new UI interface for LDAP addressbook searching anyway.

When we concocted the UI, our intent was to merge the filters.  The
reason for that is that people often don't really care about 1
addresses in parts of the organization that they never interact with.
So it turns out to be useful to be able to create several small
addressbooks (eg AcmeCo: Finance; AcmeCo: Legal).  Directory Server
deployments often have all the people for the entire company in one
big bucket, which means that using a separate base DN isn't sufficient
for this purpose.  This is also interesting from a performance point
of view (especially since addressbook still uses trees and not
outliner).  And it will also be desirable once offline LDAP
addressbooks are supported, since people will definitely want to limit
their disk space usage.  So intuition suggests doing the merging.  Is
there some reason why you'd rather not?

FWIW, I suspect I'm gonna end up implementing the filter stuff
using the filter templates in the LDAP C SDK, perhaps exposing them
as nsILDAPFilterTemplate or something.

> The address book would include every  LDAP entries from the
> preferences. So would do for the 3 hardcoded server too
> (infospace, verisign and netcenter). Are they still valid
> components in Mozilla or they just left there from the past?

They're leftover cruft.  http://bugzilla.mozilla.org/show_bug.cgi?id=79814 
has been filed about their removal.

> The only thing we should workout somehow, that the address
> book should to get notification if a new LDAP server was added
> in the autocompletion preferences. I know there were already 
> some discussion about this, but it is the time to implement
> it, because hopefully our pathces will be in soon. Should we
> have a separate bug number for this?

See http://bugzilla.mozilla.org/show_bug.cgi?id=83114 for more info
about this.

Dan
-- 

Re: I cant get LDAP working...

[Dan Mosedale]

Henrik Gemal <[EMAIL PROTECTED]> writes:
> I've downloaded a LDAP enabled build from:
> http://mozdev.org/ftp/pub/sun/
> 
> added the following lines to my prefs.js file:
> 
> user_pref("ldap_2.servers.myldap.description", "myldap");
> user_pref("ldap_2.servers.myldap.dirType", 777);
> user_pref("ldap_2.servers.myldap.filename", "myldap.mab");
> user_pref("ldap_2.servers.myldap.replication.lastChangeNumber", 0);
> user_pref("ldap_2.servers.myldap.uri", 
> "abldapdirectory://tarkin.int.tele.dk");
> 
> and where will I see LDAP autocomplete? In the compose window? In the 
> address book?

As Martin pointed out, you don't need any special builds just for the
autocomplete functionality (which shows up in the addressing fields of 
the composer window).  But you do need to first go to the 
preferences/mailnews/addressing GUI and configure an LDAP server there.

Dan


-- 

Re: Thank You!

[Dan Mosedale]

Batmensch <[EMAIL PROTECTED]> writes:
>
> I would just like to thank all of you working on the Directory stuff for 
> Mozilla.  With the recent addition of address completion using an 
> LDAP directory Mozilla has now become a useable replacement for Netscape 
> Communicator (and Outlook) at both work and home.

On behalf of all the folks who have been working on the LDAP
autocomplete, we're glad you like it!  Better yet, LDAP autocomplete
should now be even faster, as a couple of optimizations have been
checked in since you posted.

> I look forward to the new Address Book additions!  FYI, I would love to 
> help debug, but I am using the LinuxPPC platform.  Let me know if I can 
> help somehow.

Most of all, you can help us just by using it and filing any bugs or
enhancement requests in bugzilla.  One other LDAP-related feature that
could use some testing before it lands in the trunk is the LDAP/MAPI -
addressbook integration changes.  See
 for details on how 
to get and use these builds.

Dan




-- 

Re: How do you use the XPCOM Wrapper for C SDK

[Dan Mosedale]

[EMAIL PROTECTED] (Graham Gelding) writes:
> I am tring to add LDAP functionality to a Chrome. Initially all I'd
> like to do is connect to an LDAP server and read and write some
> "bookmarks.html" data.  

I'd suggest looking at Binary Runner's implementation of LDAP bookmark 
stuff; he posted a pointer to his website in this group very recently.
His work is built on top of the LDAP RDF datasource in
mozilla/directory/xpcom/datasource.

> Does anyone have any information on how to use the components 
> in mozilla/directory/xpcom/base I think that I
> can do an LDAP connect but I need to then do a search.  thanks

They're mostly documented in the IDL files there, a reasonable piece of
example code to look at that uses the LDAP XPCOM SDK is in
mozilla/xpfe/components/autocomplete/src/nsLDAPAutoCompleteSession.cpp.

Dan



-- 

Re: Thank You!

[Dan Mosedale]

Gervase Markham <[EMAIL PROTECTED]> writes:
> John Marmion wrote:
> > 
> > > John Marmion wrote:
> > > >
> > > >  We feel that there was no real conviction to QA this patch despite
> > > >  the fact that we had made it available as early as the 20th April.
> > >
> > > Who were you looking for QA from? If you wanted it from mozilla.org, did
> > > you co-ordinate with Asa?
> > 
> > Forgive my ignorance but who is Asa?
> 
> Asa is Asa Dotzler, [EMAIL PROTECTED], the head QA person (among the many
> hats he wears) for mozilla.org. I would have thought he'd be the first
> point of contact if QA resource is required.
> 
> > The problem is that changing the Address Book in Mozilla
> > means that the Commercial Tree and in particular the
> > AIM stuff needs to be tested. This testing is outside
> > of our control.
> 
> Ah. This would be a confusion between mozilla.org and Netscape. It may
> well be that the Netscape commercial tree gets spanked when Mozilla
> checkins happen. This is something that all Mozilla distributors have to
> deal with. But holding up Mozilla checkins because Netscape have not
> allocated sufficient resource to keep up with the pace of our development
> is, IMO, wrong. 

As far as I'm aware, the thing holding this up for checkin has always
been review, not Netscape QA.  It's true that Netscape would like to
QA their commercial builds first, but they still have time to do that
before the review completes.  If there's still a testing issue by the
time sr= has been granted, that's probably not enough to hold up
checkin to the mozilla tree.  But let's see if that actually turns out 
to be a problem.

Dan
-- 

Re: More questions on using own SSL lib with LDAP

[Dan Mosedale]

Rooben Garakanian <[EMAIL PROTECTED]> writes:
> -=-=-=-=-=-
> 
> Thanks for the info.  At this point in time I'm looking into these from
> client side.
> 
> Do you know what needs to replace ldapssl_client_init(cert7.db, NULL),
> ldapssl_clientauth_init(cert7.db, NULL, ...), other ldapssl_* functions or
> do you know where can I find source code for the above APIs?  Where do I
> find libssldap source code?

 has information about how
to get the source code for the C SDK.

> Do you know where can I find sample code or implementation that openSSL is
> used instead of stnadard SSL (libssldap) with LDAP?

I'm not aware of anyone having already done this work with the Mozilla 
LDAP SDK.  It's conceivable that the OpenLDAP folks might have done it 
with their SDK .

Dan
-- 

Re: LDAP autocomplete ' ' vs. '*'

[Dan Mosedale]

[EMAIL PROTECTED] (Ken Lui) writes:
> I've noticed that LDAP autocompletion works differently from
> Communicator 4.76 and Mozilla 0.9.1/0.9.2. In Communicator, if
> I enter "John Smith" and the person in the directory is "John E.
> Smith", it finds it no problem, but Mozilla doesn't find it
> unless I enter "John*Smith".
> 
> Is this behavior intended?

No; thanks for pointing it out!  I just filed bug 90535 
 on this, and there 
are more details there about what exactly is going on.

Dan
-- 

Re: LDAP autocomplete ' ' vs. '*'

[Dan Mosedale]

[EMAIL PROTECTED] (Ken Lui) writes:
> In article <9ikskp$[EMAIL PROTECTED]>,
> Dan Mosedale <[EMAIL PROTECTED]> wrote:
> >No; thanks for pointing it out!  I just filed bug 90535 
> ><http://bugzilla.mozilla.org/show_bug.cgi?id=90535> on this, and there 
> >are more details there about what exactly is going on.
> 
> Thanks for filing the bug report, Dan. I haven't submitted many bugs but
> it seems as though each time I do it, it's flagged as a duplicate even
> though I search as best as I could the current database. So I thought I
> post to the newsgroups prior to filing it this time.
> 
> I'm curious if it's a "simple" fix. For instance, modifying the Search
> Filter in Directory Server Properties's Advanced Tab. It's currently
> (objectclass=*).

It should be simple, but it's not doable through the GUI.  It'll
involve changing the default filterTemplate variable in some C++
code, though I haven't yet figured out exactly what it'll be changed
to.  It's also possible to set this variable by quitting out of
mozilla and hand-editing your prefs.js file.  Add a line of the
following format:

user_pref("ldap_2.servers.CorporateDirectory.autoComplete.filterTemplate", 
"(|(cn=%v*)(mail=%v*)(sn=%v*))");

where "CorporateDirectory" is replaced by whatever directory server
you're using.  The value of filterTemplate shown above is the current
(incorrect) default; it's gonna need to be changed to a somewhat
more complex template using "%v1" and "%v2-".  Documentation for the
format of the filter template starts here:

http://lxr.mozilla.org/mozilla/source/directory/xpcom/base/public/nsILDAPService.idl#182

Dan
-- 

Re: Autocompletion doesn't work

[Dan Mosedale]

[EMAIL PROTECTED] writes:

> 
> JMT wrote:
> 
> > Hi all,
> > I'm using Netscape 6.1. I have a problem my corporate have and LDAP
> > for addresses. I have had any problem to autocomplete addresses with
> > Netscape 4.7. It worked fine. But with N6.1 I have no luck. I have
> > checked it all and I have the same LDAP configuration on both 4.7 and
> > 6.1. What can I do to retreive names in the address line from my LDAP
> > in N6.1? Thanks in advance
> >

JMT also filed bug 91306 on this, and I'm going to try and help him
sort this out there.

> Since when does N6.1 support LDAP?

6.1 PR1 has basic LDAP autocomplete support; the support in Mozilla 0.9.2 and
the upcoming 6.1 final release have some minor enhancements from
there.

Dan
--