[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<base_dn>: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
--
