We are planning to provide a SQL interface to any LDAP
directory. This will help the database clients which access directories.
Please let me know you views on this.
we tried this same thing in the gnome-db project (http://www.gnome-db.org), writing a LDAP provider. It didn't pass the experimental step though.
We are using something like that quite successfully for IMAP4, LDAP, filesystem and DB queries in OGo. We call that the document-datasource-filemanager triangle.
By coincidence this also maps very well to the WebDAV protocol which supports queries using DASL (which also supports SQL) an base URLs in either a flat or deep way.
Of course the goal should not be to use the SQL interface to query the hierarchy! There are better APIs for that.
Eg consider the Evolution interface. It has a directory hierarchy on the left, and if you click a mail folder, you get something resembling a table on the right. If you doubleclick something you open a document.
Codewise you would use a filemanager for the tree (start using fm.listContentsOfPath("/") and walk down using filesystem API). If a folder is clicked you would retrieve a datasource for the selected folder (fm.dataSourceAtPath("/Inbox")) which you can run SQL queries on - do sorting, filtering, grouping. Finally, if you click some entry you open a document representing the record in question.
Like WebDAV, the datasource should either allow flat queries (only in the folder in question) or deep queries (include subfolders). This is indeed supported by the WebDAV DASL implementation (and SQL dialect) of Exchange 2000, ask Dan ;-).
I wrote up a little and _very_ rough text on something related: http://docs.opengroupware.org/Members/helge/DocumentAPI/DocStorage
The difficulty is in mapping the hierarchical structure of a directory to a DB interface. What have you thought about that?
Well, this should not be the goal. The datasource should take an entry point (eg the tablename represented by a DN) and allow to specify queries. You would navigate using other mechanisms to the DN in question and then use SQL to query the content - either of the specific DN or of the whole subtree.
The hardest point about mapping LDAP to SQL is that LDAP record keys are multivalued which complicates the whole API and does map very badly to everything else :-|
I would be interested on how you intend to solve that.
best regards, Helge -- OpenGroupware.org http://www.opengroupware.org/
_______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
