[LDAPGTF] Ldap Query Language

[Raphaël Ouazana-Sustowski]

Bonjour,

Le Jeu 29 octobre 2009 18:40, Emmanuel Lecharny a écrit :
> Salut les gens,
>
> petite réponse de San Francisco !
>
> Alors en ce qui concerne le LQL (Ldap Query Language), je suis sûr que
> cela peut aider. Il y a tout de me un sérieux problème : un serveur LDAP
> ne gère pas les jointures, ce qui limite franchement les possibilités,
> et j'ai peur que si on expose un langage permettant de faire qqchose du
> genre :
>
> SELECT * FROM xxx WHERE xxx.yyy IN ( SELECT * FROM zzz )
>
> on se retrouve avec des millins de requêtes LDAP vers le serveur ...
>
> Généralement, l'usage est largement plus limité cela dit. Ce qui est
> gavant, c'est de préciser tous les paramètres autres que les filters, et
> c'est là qu'un langage d'intérogation serait utile. Je verrai bien un
> truc du style :
>
> SEARCH cn, sn, gn
> FROM dc=example,dc=org SCOPE 1
> WHERE (cn=toto) AND (sn=titi)
> LIMITED TO 1000 RESPONSES
> LIMITED TO 10 SECONDS
> DEREFERENCING ALIASES
> USING CONTROL ManageDsaIt, CONTROL VLV
>
> (ce n'est qu'un exemple).

Pour les recherches, les URL LDAP répondent déjà à ce genre de
problématiques il me semble : http://tools.ietf.org/html/rfc4516#page-2

Ce que l'on cherche est un peu plus complexe, et il est vrai que ce qui
nous intéresse le plus est le fait de pouvoir faire des jointures.
On retrouve ce besoin à différents niveaux : gestion des droits,
recherches avancées, exports, etc.
Par exemple OpenLDAP a dû implémenter les sets pour gérer des contrôles
d'accès avancés :
http://www.openldap.org/faq/index.cgi?file=1133
Ils d'ailleurs basés sur une version limitée des URL LDAP.

Par ailleurs je ne suis pas encore fixé sur le style de langage à
utiliser. Les sets comme le LQL actuel sont particulièrement affreux à
relire. Je ne sais pas si un langage plus proche du SQL serait mieux
adapté. J'imagine qu'au niveau lecture ça ne peut être que mieux
(quoique...), mais au niveau parsing/performances je ne sais pas ce que ça
donne...

Raphaël.