Vu sur le blog de Ross Mayfield : SocialPoint: Best-of-Breed Wiki on Sharepoint.
J'avais assisté à une présentation de Microsoft SharePoint Portal Server à la CCI de Bordeaux. Tout n'était pas noir, mais Microsoft continuait de présenter sa solution intégrée comme étant le Graal indépassable, cette fois-ci dans le domaine du travail collaboratif. C'était d'autant plus agaçant que leur approche était clairement «orientée outil», et non pas «orientée méthode» [de travail].
La collaboration avec SharePoint de plateformes comme Socialtext, bien qu'il s'agisse certainement d'intégrations avant tout techniques, pourrait amener des utilisateurs de Socialtext à faire profiter de leurs pratiques, par porosité, certains groupes d'utilisateurs de SharePoint.
31 octobre 2006
27 octobre 2006
Je ne comprends pas Netvibes
Je suis en train de visionner le screencast de MacosX86 sur Netvibes (30'00", 68 Mo, format QuickTime, trouvé via Alternatives numériques, par ici).
C'est une vidéo qui présente Netvibes aux débutants, mais elle va jusqu'à parler du Netvibes Ecosystem.
Ce qui frappe chez Netvibes, c'est l'abondance de drag&drop, et la volonté d'intégrer tous les services possibles du web 2.0 : reader RSS, signets, calendriers, mais aussi vidéos et autres. Et là j'avoue que je ne pige pas.
Pourquoi tout redévelopper en Ajax, alors que l'OS de l'utilisateur sait déjà, ou devrait déjà savoir, faire interopérer tous ces petits bouts d'applications ? Pourquoi utiliser un lecteur dans un plugin, encapsulé dans du scripting, encapsulé dans un navigateur, encapsulé dans l'OS ? En l'occurrence, de la vidéo dans Flash dans Ajax dans Firefox dans MacOS X. Il y a un concept qui m'échappe certainement.
Pourquoi ne pas directement proposer par exemple une application XUL qui s'exécute dans Firefox ?
On n'aurait peut-être pas le même niveau d'APIs, je ne sais pas – je ne connais pas XUL.
Mais il me semble qu'à l'ère de l'Injection de Dépendances et autres Inversions de Contrôle, on ne devrait plus réaliser de telles pièces montées qui empilent autant de technos les unes au-dessus des autres.
On devrait pouvoir s'en sortir par des callbacks sur l'OS ou a minima sur le navigateur.
Ça me semblerait logique, disons.
Je sais bien que les ActiveX de Microsoft ou les applets de Sun ne valent pas mieux que le bon vieil Ajax mis au goût du jour par Google, notamment au niveau performances – pour des choses simples –, et surtout base installée.
Mais au lieu de penser HTML + Javascript + machine puissante, ne pourrait-on pas penser Firefox ?
Netvibes me fait l'effet d'une bête maquette de ce que devrait raisonnablement être l'Internet grand public.
C'est une vidéo qui présente Netvibes aux débutants, mais elle va jusqu'à parler du Netvibes Ecosystem.
Ce qui frappe chez Netvibes, c'est l'abondance de drag&drop, et la volonté d'intégrer tous les services possibles du web 2.0 : reader RSS, signets, calendriers, mais aussi vidéos et autres. Et là j'avoue que je ne pige pas.
Pourquoi tout redévelopper en Ajax, alors que l'OS de l'utilisateur sait déjà, ou devrait déjà savoir, faire interopérer tous ces petits bouts d'applications ? Pourquoi utiliser un lecteur dans un plugin, encapsulé dans du scripting, encapsulé dans un navigateur, encapsulé dans l'OS ? En l'occurrence, de la vidéo dans Flash dans Ajax dans Firefox dans MacOS X. Il y a un concept qui m'échappe certainement.
Pourquoi ne pas directement proposer par exemple une application XUL qui s'exécute dans Firefox ?
On n'aurait peut-être pas le même niveau d'APIs, je ne sais pas – je ne connais pas XUL.
Mais il me semble qu'à l'ère de l'Injection de Dépendances et autres Inversions de Contrôle, on ne devrait plus réaliser de telles pièces montées qui empilent autant de technos les unes au-dessus des autres.
On devrait pouvoir s'en sortir par des callbacks sur l'OS ou a minima sur le navigateur.
Ça me semblerait logique, disons.
Je sais bien que les ActiveX de Microsoft ou les applets de Sun ne valent pas mieux que le bon vieil Ajax mis au goût du jour par Google, notamment au niveau performances – pour des choses simples –, et surtout base installée.
Mais au lieu de penser HTML + Javascript + machine puissante, ne pourrait-on pas penser Firefox ?
Netvibes me fait l'effet d'une bête maquette de ce que devrait raisonnablement être l'Internet grand public.
23 octobre 2006
Travailler sans les transactions
Le modèle technique fait qu'il n'y a pas de transactions...
C'est facile à gérer dans le cas des mises à jour, puisqu'il s'agit simplement de poser des verrous applicatifs ou des verrous métier. Rappelons à cette occasion qu'un verrou applicatif ou métier bien posé est une garantie de la cohérence des données, tandis que tous les verrous techniques du monde auront toujours a un moment donné un ou plusieurs angles morts, et là, bien malin qui saura dépatouiller le MPD de la mort, en répondant à la fois aux exigences des fonctionnels qui veulent pouvoir modifier la base de prod' en cas de pépin (si, si) et aux nouvelles contraintes techniques des architectes (si, si).
Par ailleurs dans le modèle la cohérence des données est également assurée par leur versioning : deux parachutes valent mieux qu'un.
Pour les mises à jour des données métier, donc, pas de problème. Pour certaines modifications des données techniques non versionnées (incrémenter une date de mise à jour...), ça passe aussi. Mais que se passe-t-il en cas de destruction des données techniques ? Je ne sais pas, moi, la destruction de la session applicative, par exemple.
Si une session est en train d'être détruite, il faut interdire toute lecture et toute modification sur les objets en base attachés à cette session. Ah, zut, on n'a pas les transactions. Et à ce niveau on n'est plus versionnés...
Bon, dans ce cas particulier, la solution est simple : on s'en sort en préparant un champ de date de dernier accès à la session et en posant un verrou par une requête classique UPDATE WHERE, comme dans le cas applicatif.
Mais voici la conclusion : travailler sans les transactions impose dans certains cas de raffiner son modèle de données (ici en rajoutant un champ, s'il n'était pas prévu au départ), afin de pouvoir poser des verrous par des requêtes simples, seules garanties d'ACIDité.
Une contrainte qui offre en contrepartie à la fois une garantie absolue [ici, la cohérence des données] et une plus grande solidité du modèle, ça ne vous rappelle rien ? Eh oui, les tests.
Pour pouvoir simplement écrire certains tests, il faut parfois revoir, à l'avantage, le modèle.
C'est facile à gérer dans le cas des mises à jour, puisqu'il s'agit simplement de poser des verrous applicatifs ou des verrous métier. Rappelons à cette occasion qu'un verrou applicatif ou métier bien posé est une garantie de la cohérence des données, tandis que tous les verrous techniques du monde auront toujours a un moment donné un ou plusieurs angles morts, et là, bien malin qui saura dépatouiller le MPD de la mort, en répondant à la fois aux exigences des fonctionnels qui veulent pouvoir modifier la base de prod' en cas de pépin (si, si) et aux nouvelles contraintes techniques des architectes (si, si).
Par ailleurs dans le modèle la cohérence des données est également assurée par leur versioning : deux parachutes valent mieux qu'un.
Pour les mises à jour des données métier, donc, pas de problème. Pour certaines modifications des données techniques non versionnées (incrémenter une date de mise à jour...), ça passe aussi. Mais que se passe-t-il en cas de destruction des données techniques ? Je ne sais pas, moi, la destruction de la session applicative, par exemple.
Si une session est en train d'être détruite, il faut interdire toute lecture et toute modification sur les objets en base attachés à cette session. Ah, zut, on n'a pas les transactions. Et à ce niveau on n'est plus versionnés...
Bon, dans ce cas particulier, la solution est simple : on s'en sort en préparant un champ de date de dernier accès à la session et en posant un verrou par une requête classique UPDATE WHERE, comme dans le cas applicatif.
Mais voici la conclusion : travailler sans les transactions impose dans certains cas de raffiner son modèle de données (ici en rajoutant un champ, s'il n'était pas prévu au départ), afin de pouvoir poser des verrous par des requêtes simples, seules garanties d'ACIDité.
Une contrainte qui offre en contrepartie à la fois une garantie absolue [ici, la cohérence des données] et une plus grande solidité du modèle, ça ne vous rappelle rien ? Eh oui, les tests.
Pour pouvoir simplement écrire certains tests, il faut parfois revoir, à l'avantage, le modèle.
Dépassons les choses simples
Un article de Jakob Nielsen sur la productivité accrue ou amoindrie par un intranet : Productivity and Screen Size.
Deux citations choisies :
Je verrais un autre argument : dans la bureautique traditionnelle, les fichiers sont stockés sur le disque dur. Ce n'est pas le plus conceptuellement satisfaisant, mais la délimitation est claire. Si tant est que j'aie confiance dans mon système d'exploitation (et si non, "get a Macintosh"), tous mes fichiers sont à un endroit déterminé, je peux les retrouver en explorant le système. «Faire un backup» veut encore dire quelque chose ; ça s'adresse aux couches basses, pas à l'applicatif.
Avec le web 2.0 (Google, les blogs, les applications hébergées...) j'ai des documents un peu partout. Oh, d'accord, je parle de « documents », d'« information», et non plus de bêtes «fichiers». N'empêche que j'en ai partout, et que ce qui me sauve, ce n'est pas ma capacité à explorer, c'est ma capacité à faire des copies dans tous les coins. Ma capacité à rajouter de la «sémantique». Sauf que cette sémantique est rien moins que primaire. Et s'applique à des objets fort répandus, donc fort simples.
On passe le temps à trouver de nouvelles façons de faire des choses élémentaires, et à s'approprier des systèmes incomplets.
Moi ça me fait penser dans les années 90 aux copains qui étaient heureux sur PC de découvrir le milliard d'applications disponibles, pourtant le plus souvent nazes et incompatibles entre elles.
Pendant ce temps nous on était sur Mac, avec peu d'applications, mais des bonnes. Des applications interopérables, drag&droppables, avec des guidelines homogènes, et même quelques AppleEvents. J'ai bien dit : quelques.
Eh bien il semblerait que le Web 2.0 tienne du modèle PC. Un bordel couvré avec de bons détails et une bonne dose de tape-à-l'œil mais qui présente un ensemble au final peu fonctionnel et surtout non homogène.
Oh, pardon, il y a les... flux RSS. Dommage qu'il n'y ait aucune sémantique valable dans ces flux, hein ?
Deux citations choisies :
With more choices, it takes more time to make a decision.Et :
Skilled performance almost never happens on the Web, because users constantly encounter new pages; that is, they spend most of their time pondering options and trying to understand the content that's being presented. This is why most websites should lay off the fancy drag-and-drop features and focus on the simplest possible interaction techniques that are common to all sites.C'est le débat entre MacOS (le vrai MacOS des débuts, hein, pas son petit frère surdoué hyperactif et insupportable qu'est MacOS X) et, hrem... Windows. Entre les interfaces de Blogger (Google) et Vox (SixApart). Entre NetVibes et le reste du monde. Mais aussi entre la ligne de commande et le clickodrome. Certaines lignes de commandes sont mieux pensées que certains intranets, eh oui.
Je verrais un autre argument : dans la bureautique traditionnelle, les fichiers sont stockés sur le disque dur. Ce n'est pas le plus conceptuellement satisfaisant, mais la délimitation est claire. Si tant est que j'aie confiance dans mon système d'exploitation (et si non, "get a Macintosh"), tous mes fichiers sont à un endroit déterminé, je peux les retrouver en explorant le système. «Faire un backup» veut encore dire quelque chose ; ça s'adresse aux couches basses, pas à l'applicatif.
Avec le web 2.0 (Google, les blogs, les applications hébergées...) j'ai des documents un peu partout. Oh, d'accord, je parle de « documents », d'« information», et non plus de bêtes «fichiers». N'empêche que j'en ai partout, et que ce qui me sauve, ce n'est pas ma capacité à explorer, c'est ma capacité à faire des copies dans tous les coins. Ma capacité à rajouter de la «sémantique». Sauf que cette sémantique est rien moins que primaire. Et s'applique à des objets fort répandus, donc fort simples.
On passe le temps à trouver de nouvelles façons de faire des choses élémentaires, et à s'approprier des systèmes incomplets.
Moi ça me fait penser dans les années 90 aux copains qui étaient heureux sur PC de découvrir le milliard d'applications disponibles, pourtant le plus souvent nazes et incompatibles entre elles.
Pendant ce temps nous on était sur Mac, avec peu d'applications, mais des bonnes. Des applications interopérables, drag&droppables, avec des guidelines homogènes, et même quelques AppleEvents. J'ai bien dit : quelques.
Eh bien il semblerait que le Web 2.0 tienne du modèle PC. Un bordel couvré avec de bons détails et une bonne dose de tape-à-l'œil mais qui présente un ensemble au final peu fonctionnel et surtout non homogène.
Oh, pardon, il y a les... flux RSS. Dommage qu'il n'y ait aucune sémantique valable dans ces flux, hein ?
19 octobre 2006
L'identité numérique
Chez Tendances.IT : Qu'est-ce que l'identité numérique ? Il cite évidemment Verisign, Microsoft, Google (Google Account)...
Chez Les Fûts : ... et si l'identité n'était pas une donnée, mais un flux ?
« Les outils de gestion de l'identité numérique sont en pleine maturation, et ce domaine est jugé comme stratégique par les grands éditeurs. »Chez Bertrand Duperrin : Des outils pour gérer votre e-dentité, et Les réseaux sociaux dans l'Internet 2.
Chez Les Fûts : ... et si l'identité n'était pas une donnée, mais un flux ?
16 octobre 2006
Rencontre avec blueKiwi
Au Forum Aquitain de l'Économie Numérique jeudi dernier à la CCI de Bordeaux, j'ai rencontré Bertrand Duperrin, blogueur émérite (blog perso, blog pro), à qui j'ai demandé de me présenter de vive voix blueKiwi, le produit de la boîte dont il est éponyme, qui s'est récemment taillé un beau succès de démarrage chez Dassault Systèmes.
blueKiwi est une plateforme de blogs d'entreprise, avec des fonctionnalités bien vues, mettant davantage l'accent sur l'apport managerial que sur les prouesses techniques.
Bertrand Duperrin quant à lui est un fou du blogging, qui connaît beaucoup beaucoup de choses.
Un déjeuner et un début d'après-midi ma foi passionnants.
blueKiwi est une plateforme de blogs d'entreprise, avec des fonctionnalités bien vues, mettant davantage l'accent sur l'apport managerial que sur les prouesses techniques.
Bertrand Duperrin quant à lui est un fou du blogging, qui connaît beaucoup beaucoup de choses.
Un déjeuner et un début d'après-midi ma foi passionnants.
Une petite histoire de Usenet
Parallèlement à la révolution des comportements qu'apportent les blogs, il est à mon sens bon de se rappeler ce qu'a apporté et continue d'apporter Usenet. Car il y a du bon et même du très bon dans ce réseau.
Pour cela, je vous convie à vous pencher sur Une petite histoire de Usenet, un billet à la fois informatif et décalé sur le sujet.
Rappelons que Usenet date de 1980, NNTP de 1986, et le web des années 1990 seulement. À mon sens, les flux RSS comme le « tout-collaboratif mais néanmoins propriétaire » du web 2.0 passent à côté d'un aspect de libre partage, qui est au cœur de Usenet.
Je vous livre quelques citations de l'article, pour vous faire une idée du ton général :
« Cette "Histoire De Usenet" explore ces aspects du point de vue de la théorie psychanalytique des groupes. »
« La transmission de paquets passant de nœuds en nœuds ayant la même autorité sans système central (...) »
« (...) la mise à disposition, pour tous, d'un travail d'un des membres du groupe afin d'améliorer le fonctionnement du groupe tout entier. »
« La structure ouverte de Usenet va garantir son succès. »
« Chaque administrateur est maître chez soi, et fait ce qu'il veut. »
« Mais [la toute puissance] est limitée à leur site. Les administrateurs règnent (...) sur un royaume qui ne comporte qu'un seul sujet : eux-mêmes. »
« Sur Usenet, les pseudonymes sont mal vus, et chaque contributeur se doit d'avoir une adresse e-mail valide. »
« La fantasmatique sous-jacente est assez explicite : elle est anale – il faut garder le groupe propre (...) »
« Le troll est ainsi à Usenet ce que le masochisme est au fonctionnement psychique : un gardien de vie. »
« Au flaming, les membres du groupe réagissent parfois par un flooding. »
Bonne lecture.
Pour cela, je vous convie à vous pencher sur Une petite histoire de Usenet, un billet à la fois informatif et décalé sur le sujet.
Rappelons que Usenet date de 1980, NNTP de 1986, et le web des années 1990 seulement. À mon sens, les flux RSS comme le « tout-collaboratif mais néanmoins propriétaire » du web 2.0 passent à côté d'un aspect de libre partage, qui est au cœur de Usenet.
Je vous livre quelques citations de l'article, pour vous faire une idée du ton général :
« Cette "Histoire De Usenet" explore ces aspects du point de vue de la théorie psychanalytique des groupes. »
« La transmission de paquets passant de nœuds en nœuds ayant la même autorité sans système central (...) »
« (...) la mise à disposition, pour tous, d'un travail d'un des membres du groupe afin d'améliorer le fonctionnement du groupe tout entier. »
« La structure ouverte de Usenet va garantir son succès. »
« Chaque administrateur est maître chez soi, et fait ce qu'il veut. »
« Mais [la toute puissance] est limitée à leur site. Les administrateurs règnent (...) sur un royaume qui ne comporte qu'un seul sujet : eux-mêmes. »
« Sur Usenet, les pseudonymes sont mal vus, et chaque contributeur se doit d'avoir une adresse e-mail valide. »
« La fantasmatique sous-jacente est assez explicite : elle est anale – il faut garder le groupe propre (...) »
« Le troll est ainsi à Usenet ce que le masochisme est au fonctionnement psychique : un gardien de vie. »
« Au flaming, les membres du groupe réagissent parfois par un flooding. »
Bonne lecture.
11 octobre 2006
Le syndrome du PowerPoint
Comment, ça ne vous dit rien ? C'est le syndrome du PowerPoint, chez Temps Réels.
Ils pointent également vers un document intitulé « Comment devenir beau, riche et intelligent grâce à Word, Excel et Powerpoint », ce qui peut toujours servir.
Ils pointent également vers un document intitulé « Comment devenir beau, riche et intelligent grâce à Word, Excel et Powerpoint », ce qui peut toujours servir.
09 octobre 2006
Réplication entre centraux
Rappel d'une vieille idée (un peu à la base du truc, hein) : ça serait bien si n'importe qui pouvait installer un moteur « Les Fûts », que ce soit sur un gros serveur avec QoS, sur un LAN coupé du net, voire sur un portable, et que ces moteurs répliquent leurs données entre eux, à la manière de NNTP. J'ai bien dit « à la manière » ;-) On aurait des protocoles standard pour les échanges, et le b*rdel fonctionnerait aussi bien comme NNTP que comme un SCM... Le rêve.
À ce que j'ai compris, XWiki a aussi une vision qui parle de réplication, avec XWiki Concerto, pour lequel ils viennent d'obtenir une aide de l'ANR (Agence Nationale de la Recherche).
Pour les Fûts, l'idée est de considérer que les données, versionnées, faut-il une nouvelle fois le rappeler, sont des résultats de traitements, et que les traitements sont ce que font les centraux quand ils exécutent les commandes postées par les caches applicatifs.
Le central assure :
Quand deux centraux s'échangent des informations, on ne fait transiter que les commandes (« tout est message », rappelez-vous), pas les données. Ça n'aurait aucun sens de répliquer les données, car on est incapable d'assurer la cohérence d'une donnée isolée.
Les données sont en quelque sorte des validations par les centraux des commandes. Les commandes sont donc estampillées « non validées, locales à tel cache applicatif », ou « validées, provenant de tel central ». Les données sont estampillées « non validées, locales à tel cache applicatif », ou « validées, provenant du central auquel est rattaché le cache applicatif »
Même si elle ne concerne que les commandes, la réplication entre centraux doit s'appuyer sur des identifiants « universels », qui permettront de référencer dans tous les centraux les mêmes objets :
À ce que j'ai compris, XWiki a aussi une vision qui parle de réplication, avec XWiki Concerto, pour lequel ils viennent d'obtenir une aide de l'ANR (Agence Nationale de la Recherche).
Pour les Fûts, l'idée est de considérer que les données, versionnées, faut-il une nouvelle fois le rappeler, sont des résultats de traitements, et que les traitements sont ce que font les centraux quand ils exécutent les commandes postées par les caches applicatifs.
Le central assure :
- l'absence de conflits entre les traitements (puisque c'est lui qui les ordonnance)
- la cohérence des données
- l'indexation des données
- le versioning des données
- d'un référentiel temporel
- d'un référentiel des versions de données (« révisions »)
Quand deux centraux s'échangent des informations, on ne fait transiter que les commandes (« tout est message », rappelez-vous), pas les données. Ça n'aurait aucun sens de répliquer les données, car on est incapable d'assurer la cohérence d'une donnée isolée.
Les données sont en quelque sorte des validations par les centraux des commandes. Les commandes sont donc estampillées « non validées, locales à tel cache applicatif », ou « validées, provenant de tel central ». Les données sont estampillées « non validées, locales à tel cache applicatif », ou « validées, provenant du central auquel est rattaché le cache applicatif »
Même si elle ne concerne que les commandes, la réplication entre centraux doit s'appuyer sur des identifiants « universels », qui permettront de référencer dans tous les centraux les mêmes objets :
- identifiants d'articles (c'est le champ Message-ID dans NNTP)
- identifiants d'utilisateurs (c'est la base visible de la base du projet !)
- dates
- URLs, e-mails, adresses IP...
- types d'actions élémentaires
- autres identifiants, externes (exemple : ISBN...)
Aquitaine : Forum de l'Économie Numérique le 12/10
Ce jeudi 12 octobre se tient à Bordeaux le Forum aquitain de l'Économie Numérique. Il y aura du France Telecom, du Capgemini, du Microsoft, mais aussi du Google entre autres.
Via Bertrand Duperrin et Miss Tics.
Via Bertrand Duperrin et Miss Tics.
08 octobre 2006
05 octobre 2006
Amazon's S3 — et EC2
L'initiative Simple Storage Server (S3) d'Amazon semble être une excellente solution pour monter sans s'embêter avec des locaux et du matériel, une baie virtuelle de stockage de données.
Par ici, un développeur en parle : Replacing my home backup server with Amazon's S3.
Le tarif mensuel : $0.15/GB pour le stockage, et $0.20/GB pour le transfert. Largement dans les moyens des Fûts.
Amazon lance aussi son Elastic Compute Cloud (EC2), pour du CPU virtuel.
Par ici, un développeur en parle : Replacing my home backup server with Amazon's S3.
Le tarif mensuel : $0.15/GB pour le stockage, et $0.20/GB pour le transfert. Largement dans les moyens des Fûts.
Amazon lance aussi son Elastic Compute Cloud (EC2), pour du CPU virtuel.
04 octobre 2006
OpenAjax Alliance White Paper
Un White Paper sur Ajax chez l'OpenAjax Alliance (Google mais pas Yahoo!, Mozilla mais pas Microsoft...) : OpenAjax Alliance White Paper. Le PDF fait 23 pages, en anglais et avec de jolis schémas.
03 octobre 2006
Forum Architectes (SOA) le 19/10
C'est ballot, le jeudi 19/10 il y a un forum Architectes à Paris, centré sur SOA.
Inscription sur le site de Microsoft France.
Il faudra rentrer tôt pour la soirée Les Fûts à Talence :-)
Inscription sur le site de Microsoft France.
Il faudra rentrer tôt pour la soirée Les Fûts à Talence :-)
02 octobre 2006
Rencontre avec XWiki
De passage à Paris en fin de semaine, j'ai pu rencontrer Ludovic Dubost et Luis Arias, de XWiki.
XWiki est un wiki en Java, avec un coeur open-source, une équipe française et une communauté importante. Lire Why Is XWiki Different. Les clients peuvent demander à intégrer une surcouche spécifique à leur besoin au-dessus de XWiki. Un exemple, Chronopolys :
J'avais regardé le produit de loin au début du dev des Fûts. C'était intéressant de discuter avec son fondateur.
On a échangé nos points de vue, notamment sur la réplication de wikis, et sur l'utilité ou non de la transversalité. Intéressant.
XWiki est un wiki en Java, avec un coeur open-source, une équipe française et une communauté importante. Lire Why Is XWiki Different. Les clients peuvent demander à intégrer une surcouche spécifique à leur besoin au-dessus de XWiki. Un exemple, Chronopolys :
CHRONOPOLYS® est solution hébergée au service des collectivités locales et territoriales. CHRONOPOLYS® sert à organiser ou simplifier la gestion des projets de la collectivité, c'est-à-dire les échanges entre ses agents internes et externes : la coordination, le partage d'information, la planification, etc.Chronopolys s'appuie sur XWiki.
J'avais regardé le produit de loin au début du dev des Fûts. C'était intéressant de discuter avec son fondateur.
On a échangé nos points de vue, notamment sur la réplication de wikis, et sur l'utilité ou non de la transversalité. Intéressant.
Inscription à :
Articles (Atom)