Notes à propos des Content Repositorypre-alpha / brouillon
Suite à l'écriture du billet "Note à propos des « Content Repository » dans le cadre d'un CMS" j'ai décidé de créer ce site content-repository.info pour rassembler des réflexions à propos des Content Repository dans le cadre d'un CMS.
Mon but est d'essayer de définir quelques API, quelques "standards" non officiels de
Content Repository.
J'ai la prétention - je ne sais pas si je vais y arriver - de réaliser quelque chose de plus simple,
plus léger que JCR
(Content Repository API for Java), Apache Jackrabbit
ou CMIS.
Je sais que cela peut paraître ambitieux mais cela fais quelques années que je pense à cela, j'ai cherché si quelqu'un a déjà fait ce travail, je n'ai pas trouvé et j'ai décidé de me lancer.
J'ai créé une liste de discussion pour les personnes qui veulent échanger sur ce sujet.
News
- 17 mars 2012 - Première annonce sur Twitter ou autre
- 6 mars 2012 - Début du projet
Roadmap
- Décrire la problématique de départ, des use cases qui posent problèmes
- Réaliser une version anglaise du site
- Améliorer la partie couche modèle, donner des cas pratiques
- Faire la description d'un format d'import / export
- Décrire des cas pratiques d'utilisation d'un DVCS (Git, Mercurial) avec un Content Repository
- …
L'ordre est arbitraire.
Thématiques de réflexions
- Je souhaite définir une API Rest pour un Content Repository
- Je souhaite définir un format d'import / export pour un Content Repository
- Je souhaite trouver une solution pour intégrer Mercurial avec un Content Repository
- Je souhaite réaliser plusieurs expérimentation d'implémentation de ces idées
Quelque chose de simple ?
Déclarer que quelque chose doit être simple, ne veut pas dire grand chose, tout le monde souhaite cela ! Voici mes critères de simplicités :
- Installable via une commande, par exemple un simple
pip install charretteou unapt-get install charrette. - Une fois installé, pouvoir tester tout de suite : ajout de dossiers, fichiers… quelque
chose où l'on peut démarrer aussi facilement qu'avec par exemple CouchDB.
Avec CouchDB, on installe le serveur ensuite on peut tout de suite déposer des documents via des appels en REST, par exemple avec Curl.
Modèle de données
Liste des entités présentes dans le Content Repository :
workspacefolderresource
Les champs communs
Liste des champs qui sont communs à toutes les entités :
| Nom du champ | Type |
|---|---|
uuid |
string |
type |
workspace | folder | resource |
name |
string |
title |
unicode |
created |
datetime |
modified |
datetime |
Champs spécifiques au type "workspace"
Le type "workspace" n'a aucun champ supplémentaire.
Champs spécifiques au type "folder"
En plus des champs communs, l'entité de type "folder" a en plus :
| Nom du champ | Type |
|---|---|
parent |
uuid string |
Champs spécifiques au type "resource"
En plus des champs communs, l'entité de type "resource" a en plus :
| Nom du champ | Type |
|---|---|
parent |
uuid string |
mimetype |
string |
Proposition d'API REST
Les commandes dont l'accès se fait par le UUID de la ressource :
| Resource | Description |
|---|---|
| GET /v1/uuid/{uuid} |
Retourne le contenu d'une ressource à partir de son UUID
quelque soit son type, un workspace, un folder ou
une resource.
|
| GET /v1/uuid/{uuid}/download | Retourne le contenu d'une ressource |
| POST /v1/uuid/{uuid} | Création d'une nouvelle ressource |
| DELETE /v1/uuid/{uuid} | Suppression d'une ressource |
Les commandes dont l'accès se fait par le chemin de la ressource :
| Resource | Description |
|---|---|
| GET /v1/workspace/{path} | Retourne le contenu d'une ressource à partir de son chemin |
| GET /v1/workspace/{path}/download | Retourne le contenu d'une ressource à partir de son chemin |
| POST /v1/workspace/{path} | Création d'une nouvelle ressource |
| DELETE /v1/uuid/{path} | Suppression d'une ressource |
Exemple d'implémentation
J'ai débuté l'implémentation d'un Content Repository en suivant les spécification que j'ai indiqué sur ce site content-repository.info :
- Projet : Charrette