[LDAPGTF] QQ news suite à Apache Con 2009

Emmanuel Lecharny elecharny at apache.org
Ven 20 Nov 18:58:52 CET 2009


Francois wrote:
>>
>> 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 ? 
Ca n'a pas vraiment de sens de poser la question. LDAP travaille déjà 
avec un format de sérialization (enfin, façon de parler), à savoir les 
Entries.  JSON est juste un moyen de présenter les données sous une 
forme un peu moins lourde que XML, mais il n'y a aucune sémantique 
associée (et aucun contrôle non plus).

Dans le cas qui nous intéresse, il suffit juste de dire que le champ 
toto de la class XXX va être associé à l'attribut toto de l'objectClass 
XXX. Ensuite, c'est assez simple de faire la translation.

Petit bémol : en cas d'attribut multivalué, s'il s'agit d'une liste, il 
faudra rajouter un élément permettant l'ordonancement de la liste 
(style, une option à l'attribut). par exemple, soit une liste stockée 
dans l'attribut fruit de la classe MangerMoi :

fruit;1: orange
fruit;2: pomme
fruit;3: orange
fruit;4: banane
...

pour représenter une liste ordonnée des fruits mangés.

Dans le cas d'un ensemble non trié, c'est plus simple :

fruit: orange
fruit: pomme
fruit: orange
fruit: banane
...

Encore faut-il que le serveur LDAP le supporte !

En OpenLDAP, ils travaillent différement :
fruit: {1}orange
fruit: {2}pomme
fruit: {3}orange
fruit: {4}banane
...

Je sais, c'est moche ...

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




More information about the LDAPGTF mailing list