[LDAPGTF] Ldap Query Language

[Emmanuel Lecharny]

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).

On pourrait assez facilement définir un langage minimal prenant en 
compte le SEARCH, ainsi que le DELETE et MODIFY.


Sébastien Bahloul wrote:
> Bonjour,
>
> Comme c'est toujours plus facile d'être d'accord avec soi-même et pour 
> expliciter un peu le pourquoi du comment, voici un peu d'histoire et les 
> besoins qui en sont à l'origine avec :)
>
> Le besoin initial était un langage de contrôle d'accès pouvant facilement 
> exprimer une règle fonctionnelle basée sur un DIT LDAP complexe, d'oû le 
> Advanced Access Control List (AACL pour les intimes)
>
> Le sous-ensemble de ce concept en langage d'interrogation a été décliné sous 
> le nom un peu pompeux de Ldap Query Language qui complète notre fonction 
> search avec les autres fonctions qui sont nécessaires pour exprimer tout type 
> de relation depuis le passage par un attribut, la recherche du premier parent 
> satisfaisant un filtre, la concaténation et l'intersection d'ensemble de 
> résultats, ... . Avec une petite dizaine de fonctions on peut donc couvrir pas 
> mal d'usages.
>
> Pour que cela fonctionne, il faut évidemment que tout cela soit interpréter 
> dans une couche applicative qui puisse manipuler les chaînes de caractères. 
> D'où une première implémentation en javacc, puis une utilisation du moteur 
> Javascript Rhino (dans le projet LSC).
>
> Pour conclure, le besoin me semble donc bien réel, même si la définition et 
> l'implémentation actuelle souffrent probablement quelques limites de jeunesse.
>
> Cordialement,
>
> Le jeudi 29 octobre 2009 13:53:06, Francois a écrit :
>   
>> Salut les gens !
>>
>> Allez, je lance un sujet de discussion qui peut se faire par mail, pour
>> faire un peu bouger cette liste.
>>
>> Très rapidemment, lorsqu'on veut faire du LDAP, on se retrouve à manquer
>> d'un langage de requetage composable, comme le SQL. Le besoins est de
>> pouvoir effectuer des requetes du types "je veux tous les noeud sous tel
>> root dont un des fils à tel attribut à telle valeur". Bref, des jointures.
>>
>> Sébastien Balhoul, ici présent, travail depuis longtemps autour de cette
>> problèmatique. J'ai même eu la chance de pouvoir utiliser le fruit de
>> son travail dans le cadre d'InterLDAP[1]. Mais ce travail est trop peu
>> connu à sens, alors que le besoin est récurrent (ou bien suis-je le seul
>> à vouloir faire ce genre de requetes à longueur de journée ?).
>>
>> Du coup, je me dis deux choses:
>> D'un part, que peut être d'autres ont eu le même type démarche, que
>> chacun à créé sa bibliothèque de requetage au dessus de LDAP pour ses
>> applis, et qu'au final, sa fait beaucoup de travail fait et refait sans
>> pouvoir profiter les uns du travail, des erreurs et des idées des
>> autres, et pourquoi pas arriver à une API commune.
>>
>> Et d'autre part, qu'à terme, ca pourrait être vraiment bien de pousser
>> l'idée que ce language de requete soit intégré au niveau des serveurs,
>> et non plus dans des lib clientes.
>>
>> Alors, ca vaut le coup d'en discuter ?
>>
>> [1] http://wiki.interldap.ow2.org/xwiki/bin/view/Main/AACLSDocUse
>>
>> --
>> Francois Armand
>> _______________________________________________
>> LDAPGTF mailing list
>> LDAPGTF at lists.ldapgtf.org
>> http://ldapgtf.org/mailman/listinfo/ldapgtf
>>     
>
>   


-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org