[LDAPGTF] QQ news suite à Apache Con 2009

[Francois]

On 20/11/2009 17:40, Emmanuel Lecharny wrote:
>> Est-ce que ce genre d'idées va dans le sens que tu pensais ?
> Je ne lis pas dans les pensées de François, mais voici mon avis sur le
> sujet :

Au début, c'était juste de faire un peu de pub en profitant d'un buzz. 
Et pourquoi pas de garder à l'oeil ces repositories avec l'idée de 
pouvoir les utiliser comme back-end distribué pour un annuaire LDAP (ils 
sont super bas niveau et y'en a pas deux qui parlent le même 
protocole^W^W^W^W ont la même API, LDAP est un protocole normalisé 
présentable au monde extérieur).

> 1) On stocke les objets dans un attribut, brutalement après
> sérialization, avec une clé permettant de retrouver l'object (clé qui
> serait dans le RDN)
> 2) On créé un ObjectClass décrivant l'objet, et on créé une entry par
> instance à stocker, avec une clé sélectionnée pour le DN (l'UUID, par
> exemple ?)
>
> La première approche est franchement chevaline, mais pour une approche
> HTable, ça peut suffire (à condition de bien choisir sa clé)

Et en choisissant bien la sérialisation aussi.

> La second approche nécessite d'effectuer un mapping plus pointu, et pose
> le problème des références sur d'autres objets, qui va se traduire en
> général par N lectures dans la base...
>
> Ce n'est pas évident... La seconde approche est clairement simple à
> mettre en oeuvre si on travaille avec des objets 'plats' (sans
> références sur d'autres objets).

Oui, mais on peut aussi avoir des restrictions. Tous ces stores en sont 
pleins, et la plupart forcent l'utilisateur à faire une grosse partie du 
boulot sur le sujet de la référence d'autres objets (en générale, c'est 
"ton arbre doit être completement sérialisable dans le format que je 
connais").

Peut être qu'on pourrait trouver un milieu entre les deux versions 
proposées, en prenant un format simple à décrire, au pif... hum... JSON. 
On fait un schéma pour ce format de sérialization, et ensuite, on 
utilise le mapping qui va bien entre le langage de programmation client 
et ce back-end (tiens, ca tombe bien, la moitié de l'univers travaille à 
la sérialization d'objets vers JSON).

Ca ressemblerait à quoi un schema LDAP pour JSON ? La version barbare 
est l'équivalent de ce que fait CouchDB (clé => dump JSON), mais on doit 
pouvoir affiner un peu.
Pour rappel, json: http://www.json.org/


> Petite précision : si on injecte un schéma à la volée (ce qui n'est pas
> forcément impossible, voir avec son vendeur préféré ;), il ffaut aussi
> être capable de générer un index à la volée, sinon, l'approche 2 est
> inutile... (sauf à définit ces index avant le lancement de la base).

Bonne remarque.

-- 
Francois ARMAND
http://fanf42.blogspot.com