[Date Prev][Date Next]
Re: Need a multi-client schema
Carr, Chris wrote:
From: Howard Chu [mailto:email@example.com]
Sent: 22 January 2008 03:16
Still, it would probably be worth spending a few days effort to
different schema together and define a superset that contains all of
respective customizations. Then you can use back-relay and the rewrite
to present the client-specific views to each client. The result of
would make a fine entry in the FAQ-o-Matic.
Thanks for the replies. Is there another way of doing this? Instead of
trying to create some super-schema for my server (which would be
outdated every time any of the clients altered its schema), could I not
simply replace each client's schema with a consistent one?
Let's say that the three clients I want to share contacts are Outlook,
Evolution and Thunderbird. Would it be possible to use the AD schema for
the LDAP server and for all three clients, replacing the default
schemata of Evolution and Thunderbird?
Since Evolution and Thunderbird are open source, you can of course modify them
to do whatever you want.
If this is not possible, how would the super-schema solution propagate
changes made by one client to the data visible to another? (Presumably
this is where "back-relay and the rewrite overlay" come in - will have
to read up on these.)
Yes, you would create one main directory with the superset of data elements
and use back-relay to present distinct virtual directories to each client so
they will only see the attributes they're looking for. The rewrite overlay
would translate attribute names back and forth so that there aren't multiple
copies of identical data.
I found the Evolution schema, though I don't know how up-to-date it is:
... so I can try combining it with the Mozilla schema and see how far I
get before taking on Outlook. Does anyone know where to find the AD
schema? I can find dozens of pages about it, but can't actually download
it from any of them.
As usual, Microsoft is not very forthcoming with docs, but there's quite a bit
of analysis already done here.
Yet another way of looking at this is to consider that the combination
of core, cosine and inetorgperson provides all the fields you need in a
basic address book, and it should be possible to get all the clients (at
least the non-MS ones) using that.
I'll report back if I make any progress, but Google shows that people
have been struggling with this problem since the dawn of LDAP, so I'm
not overly optimistic.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/