Je suis d’accord avec vous sur le fait qu’un document soit récupérable est une bonne chose.

La conf. du nombre de jour que j’utilisais était 2 pour minimiser le problème … dans la durée.

Mais 14 ou 2jours, lorsque l’on fait un gros import qui génère au moins un déplacement par document, cela résulte en un repository qui est deux fois trop gros.
(Et le changement de ce paramètre implique de redémarrer le serveur)

Je pense à un import vers un espace qui possède une règle pour déplacer les documents incoming.

Pour ce genre de traitements, il faudrait que la suppression puisse être demandée « sans poubelle ».

Voila pour ce cas d’import.
J’avais pour projet de faire une système qui classe automatiquement les documents qui arrivent/sont mis dans un espace d’une certaine nature. Une sorte de classement automatique en cascade (imaginez un jeu de patchinko) basé sur par exemple les mots clés/les mots les plus utilisés dans le document.
Cela n’est pas pertinent du fait de cette « étape poubelle ».

Pour un autre import où j’ai eu les métadata dans un fichier excel et les documents en filesystem, mon parser s’executait obligatoirement dans une autre VM qu’Alfresco, mais sur la même machine.
A l’époque (v2.0), la seule option était d’utiliser le web service pour importer mes documents.
Ce qui à mon goût est inutilement coûteux, tant en temps de programmation (complexité des WS par rapport à la simplicité de l’API JCR) qu’en temps de transport.

Voila pour le mal que j’en ai à dire.
J’ai aussi beaucoup de bien à en dire aussi : OS, forums réactifs, communauté, offres commerciales, diversité des API , choix des composants OS, …. , et tient sur une clé USB !

Ils sont dans le groupe de l’API CMIS, ce qui signifie que même en choisissant Alfresco, on peut eviter le « vendor lock-in »

Les WebScripts sont pertinents.
Share est intéressant.

C’est sans aucun doute un bon produit.

JCR par RMI n’a jamais été créé pour être rapide, et n’est d’ailleurs clairement pas conseillé. Il vaut bien mieux utiliser des technologies de Web Services comme SOAP ou REST qui ont été créées pour cela. Et là dessus, Alfresco est rapide et tient très bien la charge, c’est ce que j’ai pu constater dernièrement en tout cas.

Il existe une autre petite entreprise française qui fait tout cela très bien : eXo Platform (http://www.exoplatform.com). Portail, ECM, …. le tout en suivant les standards (La liste des JSRs implémentée est longue). Tous les détails sont ici : http://www.exoplatform.com/portal/public/website/product/exosolution

PS : Je travaille pour eXo Platform.

C’est sûr que l’on n’a pas la souplesse et la puissance d’un Alfresco mais si vous voulez une solution rapide à mettre en œuvre et avec de nombreuses fonctionnalités prêtes à l’emploi.

J’imagine qu’une certaine société où Arnaud s’en est allé pourrait dire la même chose…

PS: je travaille pour Silverpeas

Mon supérieur souhaite mettre en place dans notre service marketing sharepoint et me demande de me renseigner sur l’outil mais je n’y connais rien.

Quelques infos général sur l’outil ou les prestataires spécialisés

Merci

Elle peut aussi provoquer des surprises.
Je me souviens que déplacer un document d’un espace vers un autre impliquait une copie et une suppression !
Logique me direz vous ?
En cas de déplacement d’un doc en passant par plusieurs espaces, les clones successifs étaient poubellisés et donc gardés sur disque pendant X jours (14 par défaut?) causant une énorme utilisation du stockage.

Je ne sais pas si ce comportement est toujours d’actualité.

Avec une version précédente, ma première déception a été le support de JCR en intra-VM, JCR par RMI étant bien lent.

Dur de devoir faire du web service pour faire communiquer deux VM sur une même machine (dans le cas d’un gros import avec setting des métadonnées) !

A l’occasion, jetez un oeil sur le dernier Nuxeo.

Jerome