Here's my 2c on this matter.
I believe that LDAP is most useful to enterprise customers, and it's my
understanding that some of these users have an absolute requirement to
be able to control *every* aspect of the browser. Not only for
user-support issues, but for security issues.
I don't know the details of the data you're proposing to put in a file
or the prefs, but if it has any impact on the function of the client,
someone out there will want to lock it. Putting it in a file makes that
goal more difficult, while putting it in a pref file simplifies that
task. With the enterprise tools, they will be able to set and lock
preferences, while deploying to multiple platforms from centralised
management positions.
I've also cc'd chipc who may have additional comments.
Eddy Kim
Paul Sandoz wrote:
>
> >> 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-attrib
> ute-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.
>
> >>
> >> /*
> >> 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...
>
> >> 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.
> >
>
> Yep, most are inetOrg or from the super classes.
> I will update.
>
> Thanks,
> Paul.
>
> | ? + ? = To question
> ----------------\
> Paul Sandoz
> x19219
> +353-1-8199219
>
