Re: gnome-about-me

[Chris Toshok <toshok ximian com>]

On Tue, 2004-09-21 at 19:50 +0100, Alan Cox wrote:
> On Maw, 2004-09-21 at 18:26, Sean Middleditch wrote:
> > I'd recommend using a library like libuser (available in Fedora, don't
> > know if it's a Red Hat thing or not), which provides an API for querying
> > and changing that sort of information.
> 
> According to its own docs yes, although its by no means system specific.
> 
> > Also dont' forget that Evolution has some (all) of this information, so
> > your app could also just be an additional simple front-end to e-d-s.
> > Especially if e-d-s already has (or will have) hooks for updating the
> > system user information.
> 
> Evolution seems to favour Novell Groupwise LDAP formats over pure
> RFC2307 formats[1]. One of the things any infrastructure like this is
> going to have to do is to support the interpretation of a lot of
> different LDAP profiles each designed by one large company or another to
> lock customers into their proprietary components.

Actually, modulo bugs, evolution favours the formats provided in the
LDAPv3 schema (rfc 2252/2256) and the calendar schema rfc (2739).  There
are a few non-standard attributes defined in evolutionperson.schema, but
evolution can deal just fine with that schema not being present.  Also
as attributes in RFC's are found to conflict (as they were with the
calendar/freebusy attributes), the ones in evolutionperson.schema are
deprecated.  There is certainly nothing groupwise specific in the ldap
backend, and you'd have to be pretty crack-adled to think so..  The LDAP
backend was written (and has remained largely unchanged, schema-wise)
over 4 years ago, before I'd even heard of Groupwise (or eDirectory) :)

RFC2307 isn't useful to evolution.  Evolution isn't meant to be a tool
used by sysadmins to maintain user databases, although that's not to say
it couldn't be hacked to do so (not that I think it should ever be -
there are better, simpler, more powerful tools for this.)  Evolution is
meant to be used to store your contact information.  The LDAP backend is
for use in corporate environments for company-wide addressbooks and for
users that want to maintain some sort of network accessible addressbook
to complement imap.  The backend is regrettably hardcoded to use a
specific set of attributes, and the front end contact editor is
hardcoded as well.  But even with the hardcoded nature of the
frontend/backend, it does what it's meant to do rather well, IMO.

Now, when I say RFC2307 isn't useful wrt evolution, I don't mean it
can't coexist.  There's nothing stopping admins from populating an ldap
server with objects that include both the attributes defined in rfc 2307
and those attributes that evolution knows how to deal with.  There will
be certain attributes of those ldap objects that won't be accessible via
evolution, but they won't be clobbered when evolution saves changes.

> That's also a great opportunity because nobody really does that well and
> interworks in such environments.

I agree here, and it was always my plan to provide some sort of
plugability with the ldap backend.  Allowing the user (or administrator
when installing evo) to configure which ldap attributes map to which
vcard attributes has been (unfortunately at the bottom) of my TODO list
for a long time now.  So, potentially we could allow some xml format to
describe the field mapping for the ldap backend, plus an EPlugin to
modify the contents/behavior of the contact editor, and everyone gets
what they want.

Chris