[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenLDAP SQL Backend



	First of Tcl sucks. That is my personal opinion. TkPerl on the
other hand is pretty useful. Now with that out the way, ODBC let's your
implementation access more databases with less functionality which I don't
think is much of a problem since I don't think we need every last super
duper feature from a given database. 

	I think that you are trying to reinvent the wheel with the access
language. PerlDAP exists already and seems to work relatively well. You
can get it off of www.mozilla.org either as a tarball or as a CVS
checkout.

	With a database on the backend, it allows me to do shoot myself in
the foot operations such as associate users with machines in the database
itself instead of doing say an alias reference inside ldap. I am not
particularly interested in replicating DNS data in LDAP space but I do
need a way to associate users and their machines since many of my users
have multiple machines and we have multiple buildings now. If anyone has a
good idea as to how to solve this, speak up. Additionally, SAP is getting
implemented at here and apparently the HR and asset tracking modules are
getting put in. I would love to have a way to synchronize data between
those databases and ldap. 

--Jauder

On Tue, 8 Sep 1998, Lucio de Re wrote:

> Where I'd like to go is to define an access language (I keep thinking 
> Tcl, because I'm moderately familiar with it, but Perl or Python could 
> be equally good candidates) that makes the directory easier to search 
> and update, and adds relational database capabilities to it, possibly 
> by reaching towards the back end, or perhaps by layering the directory 
> on top of the relational database in some as yet undefined manner.
> 
> All this is pie-in-the-sky, but the relational database model is 
> theoretically generic enough to represent all known database models (I 
> may be overstepping my understanding at this point) and it would be 
> interesting to see where the intersection of directory databases and 
> relational databases is.
> 
> Pure speculation, but intriguing enough to do a bit of investigating.  
> My main thrust at this point is to needle Kurt into finishing porting 
> OpenLDAP to autoconf, while I tweak the NetBSD configuration, then I'd 
> like to look at producing a Tcl-based shell to supplement the existing 
> client tools.
> 
> If Predrag is keen to look at PostgreSQL, I'll gladly help once I've 
> managed to print the necessary documentation, but I would still try to 
> slip behind SQL and closer to the database engine, if at all possible.  
> Presumably, ODBC is more tightly coupled to the database than SQL?
> 
> ++L
> 
>