[Mono-list] System.Data.DirectoryClient

[Helge Hess]

On 05.12.2003, at 16:58, Rodrigo Moya wrote:
>> 	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/