[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LDAP (and Asterisk) integration, was: New user question: egroupware
- Subject: Re: LDAP (and Asterisk) integration, was: New user question: egroupware
- From: "Chris Travers" <..hidden..>
- Date: Fri, 17 Nov 2006 15:57:54 -0800
On 11/17/06, Stroller <..hidden..> wrote:
On 17 Nov 2006, at 18:37, Chris Travers wrote:
>> ... With OpenLDAP
>> 2.1, you can build a backend called sql-back that let's you
>> expose
>> SQL tables through LDAP. It takes writing some queries custom to
>> the SQL application and building some tables or views to map
>> between
>> the schema. If I did this, I could reduce the duplication between
>> having my customers' contact info in my LDAP addressbook and
>> SQL-Ledger.
>> http://nakedape.cc/wiki/ApplicationNotes_2fSqlLedgerNotes
> ...
> Another (possibly better) option would be to have an option to export
> LDIF files that could be imported into another OpenLDAP server.
Would this not result in entries in the LDAP schema which can be
edited by LDAP clients but not returned to the L-SMB database?
Not necessarily. Depends on the implementation, access controls, etc.
It would be quite possible to set up OpenLDAP to avoid this problem.
But again, premature optimization is the root of all evil. We go with
the easy way (SQL backend) first and then figure out what to do later.
In regard the whole integration of L-SMB's customer db with other
apps, the biggest nightmares I can conceive are the possibility of
Joe Salesman editing the company name of an entry (say in line with
the customer's new CAPITALisation policy), and this getting back to L-
SMB & throwing out all invoices already assigned to the customer.
Again, this is an issue that needs to be carefully addressed in the
implementation. In general, I am very aware of the issues involved in
such integrations (having had to write my own distributed replication
scripts in the past). Issues like tracking unique records across
database systems which may not have the same table structures isn't a
hard problem to solve, however. Conflict resolution, however, is a
bigger issue.
I had envisioned a read-only interface to SL / L-SMB's customer db -
speaking for myself I need no more to be VERY happy.
Agreed on the read-only interface.
One thing to bear in mind is this:
LDAP integration is one of those things where one can create a very
simple solution very quickly. However, after a little while it
becomes very clear that integration with LDAP is something that may
give some benefits but often you end up with the worst of both worlds.
So just because it works doesn't mean it won't have problems. And
LDAP integration poses a number of inherent problems in this regard.
Not that we can't get something that works well enough, though...
Best Wishes,
Chris Travers