Et oui effectivement, il vaut mieux que CMIS ne remplace pas JSR.. mais fasse oublier rapidement qu’un jour une norme fut associé à un langage de dév.

Tous ce qui va dans le sens de l’interopérabilité est souhaitable

J’ai la même vision de JSR-170 et son adoption très relative (doux euphémisme).

La faute de la lettre J d’abord, trop restrictive, mais aussi à des implémentations variées (la faute à une spécification qui décrit une API au lieu de décrire un protocole) et plein de petits défauts qui font qu’on peut très vite regretter ce choix !

L’approche CMIS est vraiment intéressante. D’abord parce que avoir réussi à laisser le choix entre REST et SOA, ça ne frustrera pas les développeurs. Ensuite parce que à défaut d’être parfaite (ça reste une version 0.5), la spécification attaque les choses du bon coté. Spécifier à haut niveau, c’est laisser toute la latitude pour la mise en œuvre et ça va faciliter grandement l’adoption sans forcer à revoir l’application sous-jacente de fond en comble.

Ça ouvre pas mal de nouvelles possibilités, et une fois que les principaux acteurs auront leur implémentation on pourra enfin faire cohabiter des entrepôts variés et peut être surtout penser de nouvelles applications.

Bien sûr il reste un peu de chemin avant que CMIS tienne toutes ses promesses et soit LA norme, mais ça pourrait aller assez vite (déjà les acteurs du groupe de travail ont tous une version très avancée, voir finalisée).

Alors oui, il parait que CMIS ne vient pas remplacer JSR170 … mais je crois que c’est justement ce qui rend la nouvelle approche plus crédible :p