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_String, "CellularNumber", "carphone"},
>
> // No Home* properties defined yet
> {MozillaProperty_String, "CellularNumber", "cellphone"},
>
> {MozillaProperty_String, "WorkAddress", "postofficebox"},
> {MozillaProperty_String, "WorkAddress", "streetaddress"},
> {MozillaProperty_String, "WorkCity", "l"},
> {MozillaProperty_String, "WorkCity", "locality"},
> {MozillaProperty_String, "WorkState", "st"},
> {MozillaProperty_String, "WorkState", "region"},
> {MozillaProperty_String, "WorkZipCode", "postalcode"},
> {MozillaProperty_String, "WorkZipCode", "zip"},
> {MozillaProperty_String, "WorkCountry", "countryname"},
>
> {MozillaProperty_String, "JobTitle", "title"},
> {MozillaProperty_String, "Department", "ou"},
> {MozillaProperty_String, "Department", "orgunit"},
> {MozillaProperty_String, "Department", "department"},
> {MozillaProperty_String, "Department", "departmentnumber"},
> {MozillaProperty_String, "Company", "o"},
> {MozillaProperty_String, "Company", "company"},
> {MozillaProperty_String, "WorkCountry", "countryname"},
>
> {MozillaProperty_String, "WebPage1", "homeurl"},
> {MozillaProperty_String, "WebPage2", "workurl"},
>
> {MozillaProperty_String, "BirthYear", "birthyear"},
>
> {MozillaProperty_String, "Custom1", "custom1"},
> {MozillaProperty_String, "Custom2", "custom2"},
> {MozillaProperty_String, "Custom3", "custom3"},
> {MozillaProperty_String, "Custom4", "custom4"},
>
> {MozillaProperty_String, "Notes", "notes"},
> {MozillaProperty_String, "Notes", "description"},
>
> {MozillaProperty_Boolean, "SendPlainText", "xmozillausehtmlmail"},
> {MozillaProperty_Int, "LastModifiedDate", "modifytimestamp"}
> };
>
> -=-=-=-=-=-
Anyway, nice work!
Dan
--
