Au niveau architecture, il commence à y avoir pas mal d'informatio disponible ici: http://www.nuxeo.org.
Au niveau architecture, Nuxeo Runtime et Nuxeo Core sont très intéressants et nous en sommes fiers! :-)
Au niveau fonctionnel, un des principal intérêt et la fusion entre les fonctions de collaboration et de GED. Et quelques suprises qui devraient arriver dans les prochains mois/semaines tel que l'intégration profonde du mail de l'instant messaging, de la signature électroniques, etc.
Nous sommes tout a fait disponible pour expliquer plus en détail tout cela.
Parce que Documentum n'a pas du tout fait le pari de Java dès le départ? Parce que Nuxeo5 offre plus d'avantages que Documentum? Parce qu'il est meilleurs techniquement, fonctionnellement et moins cher à mettre en oeuvre?
Pour info, Documentum c'est du bon vieux C avec une architecture qui date de 15 ans...
Oui c'est comme ça que ça fonctionne. Un modèle OpenOffice.org adapté à DocBook est inclut dans le package. Il faut faire attention à la différence Style de Caractère et Style de Paragraphe (exemple : paragraphe en Text Body et toto.txt en Filename).
Ta vision des choses est bonne si tu pars du principe qu'avec Zope on gère des fichiers. Mais ce n'est pas le cas, avec Zope on gère des objets, pas des fichiers.
La ZODB n'est pas qu'une base de donnée ou un système de fichier. C'est, basiquement, un depôt d'objet qui offre principalement 2 services:
- Un mécanisme de persistance objet
- Un système de stockage
Le mécanisme de persistance permet de laisser le soin au système de gérer le stockage des objets. Cela évite ainsi au développeur de gérer pour chaque classe le stockage des objets (et donc, comme c'est le cas sans mécanisme de persistance de gérer à lamain le mapping objet <-> stockage physique).
Cette partie est d'ailleurs paramétrable via APE (Adaptable Persistance) qui permet de définir la façon dont on souhaite réellement stocker les objets : en tant que tel dans le dépot, sur le FS, sur le FS et dans le dépôt, dans le dépot et dans une base SQL, complètement dans une base SQL, etc. APE permet de définir complètement le mapping entre les objets et leur stockage.
Le système de stockage offre un mécanisme pour stocker physiquement le dépôt d'objet. Le mécanisme de base (FileStorage) stocke le dépôt dans un gros fichier ce qui a l'avantage d'être simple à mettre en place mais a la limite de la taille du fichier et des capacités de manipulation d'un gros fichier par l'OS.
Mais ce n'est pas grave. Il existe, en effet, de nombreux systèmes de stockage (ZODB Storage) qui permettent de stocker le dépôt de multiple façon : un fichier par objet dans une hiérarchie de répertoires (DirectoryStorage), une base Oracle (OracleStorage), une base BerkeleyDB (BSDDBStorage), distribué (sur un serveur de base Zope : ZEO), etc.
Une même instance de Zope peut d'ailleurs utiliser simultanément plusieurs stockages suivant les besoins (par exemple un DirectoryStorage pour les données et un BSDDBStorage pour les sessions).
Si l'on voit la couche ZODB comme une simple base de donnée, on peut considérer que c'est une mauvaise base, mais si l'on la considère comme un mécanisme de persistance, on constate que c'est un formidable mécanisme de persistance qui arrive au niveau de ce que l'on peut trouver dans le monde J2EE. Il ne faut pas se tromper d'utilisation. De même que si l'on utilise Zope pour simplement gérer des fichiers, je pense que ce n'est pas un bon choix. En revanche si on utilie Zope pour écrire des application web de gestion, travail collaboratif, gestion de contenu ou même traitement comptable, je pense que c'est un excellent choix.
Enfin, la partie de gestion physique (I/O) de la ZODB est écrite en C, pas en python. Donc ce qui manipule le gros fichier c'est du C :-)
Et vu les quelques sites importants, il est clair que ça tient la charge.
De plus Python est très utilisé dans l'industrie. c'est pas exemple language de script de CodeAster (un gros logiciel de calcul thermo-mécanique par EDF : http://www.codeaster.org(...)). Il me semble aussi que c'est utilisé par OpenCascade. Pour plus d'information la dessus tu peux consulter python.org.
Enfin, Python n'est pas fait pour être un language système à mon sens, mais un language de script de de prototypage. Dans Zope, par exemple les morceaux qui doivent aller très vite sont écrit en C et toute la partie interface et modules applicatifs en Python.
Dans le cas présent, CGEY fait appel à NUXEO pour ce projet. La Villed e Lyon a certainement préféré l'expérience et la solution proposée par CGEY, en plus de CPS.
Un "Content Network" (le terme consacré est "Content Delivery Network) n'est pas un système type Gnutella / Napster / Whatever, mais un système de cache distribué permettant de distribuer le contenu là où il est demandé. C'est un fonctionnement à la Akamai, qui permet de mettre en place un maillage de caches pour servir plus vite le contenu en le plaçant plus près de l'internaute.
Bref, rien a voir avec Gnutella, mais ce type de système est extrêment intéressant pour désengorger le net et distribuer le cache de façon optimale. De plus, un standard dans le domaine est le bien venu car il permettrait, dans le meilleur des mondes, de mutualiser et fédérer les systèmes de caches distribués existants et d'utiliser l'espace de stockage perdu, des utilisateurs, pour stocker le cache de l'Internet !
Nuxeo a conçu et mis en place toute l'infrastructure de gestion de contenu du site, ainsi que la présentation automatique des résultats validés des élections (qui ont d'ailleurs entrainées un pic de charge important, permettant de démontrer la stabilité de Zope, même sous de forte charge -- techno ZEO pour le clustering).
[^] # Re: Troll Pyhton vs Java mis à part
Posté par Eric Barroca . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 2.
Merci de recentrer.
Au niveau architecture, il commence à y avoir pas mal d'informatio disponible ici: http://www.nuxeo.org.
Au niveau architecture, Nuxeo Runtime et Nuxeo Core sont très intéressants et nous en sommes fiers! :-)
Au niveau fonctionnel, un des principal intérêt et la fusion entre les fonctions de collaboration et de GED. Et quelques suprises qui devraient arriver dans les prochains mois/semaines tel que l'intégration profonde du mail de l'instant messaging, de la signature électroniques, etc.
Nous sommes tout a fait disponible pour expliquer plus en détail tout cela.
Bonne soirée,
EB.
[^] # Re: Bonne nouvelle ?
Posté par Eric Barroca . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 3.
Pour info, Documentum c'est du bon vieux C avec une architecture qui date de 15 ans...
Bonne soirée,
EB.
[^] # Re: Pourquoi pas mais...
Posté par Eric Barroca . En réponse à la dépêche ooo2dbk : Générer du DocBook à partir de documents OpenOffice.org. Évalué à 2.
[^] # Re: Quels éditeurs pour DocBook ?
Posté par Eric Barroca . En réponse à la dépêche ooo2dbk : Générer du DocBook à partir de documents OpenOffice.org. Évalué à 5.
[^] # Re: Première version packagée de CPS3
Posté par Eric Barroca . En réponse à la dépêche Première version packagée de CPS3. Évalué à 6.
La ZODB n'est pas qu'une base de donnée ou un système de fichier. C'est, basiquement, un depôt d'objet qui offre principalement 2 services:
- Un mécanisme de persistance objet
- Un système de stockage
Le mécanisme de persistance permet de laisser le soin au système de gérer le stockage des objets. Cela évite ainsi au développeur de gérer pour chaque classe le stockage des objets (et donc, comme c'est le cas sans mécanisme de persistance de gérer à lamain le mapping objet <-> stockage physique).
Cette partie est d'ailleurs paramétrable via APE (Adaptable Persistance) qui permet de définir la façon dont on souhaite réellement stocker les objets : en tant que tel dans le dépot, sur le FS, sur le FS et dans le dépôt, dans le dépot et dans une base SQL, complètement dans une base SQL, etc. APE permet de définir complètement le mapping entre les objets et leur stockage.
Le système de stockage offre un mécanisme pour stocker physiquement le dépôt d'objet. Le mécanisme de base (FileStorage) stocke le dépôt dans un gros fichier ce qui a l'avantage d'être simple à mettre en place mais a la limite de la taille du fichier et des capacités de manipulation d'un gros fichier par l'OS.
Mais ce n'est pas grave. Il existe, en effet, de nombreux systèmes de stockage (ZODB Storage) qui permettent de stocker le dépôt de multiple façon : un fichier par objet dans une hiérarchie de répertoires (DirectoryStorage), une base Oracle (OracleStorage), une base BerkeleyDB (BSDDBStorage), distribué (sur un serveur de base Zope : ZEO), etc.
Une même instance de Zope peut d'ailleurs utiliser simultanément plusieurs stockages suivant les besoins (par exemple un DirectoryStorage pour les données et un BSDDBStorage pour les sessions).
Si l'on voit la couche ZODB comme une simple base de donnée, on peut considérer que c'est une mauvaise base, mais si l'on la considère comme un mécanisme de persistance, on constate que c'est un formidable mécanisme de persistance qui arrive au niveau de ce que l'on peut trouver dans le monde J2EE. Il ne faut pas se tromper d'utilisation. De même que si l'on utilise Zope pour simplement gérer des fichiers, je pense que ce n'est pas un bon choix. En revanche si on utilie Zope pour écrire des application web de gestion, travail collaboratif, gestion de contenu ou même traitement comptable, je pense que c'est un excellent choix.
Enfin, la partie de gestion physique (I/O) de la ZODB est écrite en C, pas en python. Donc ce qui manipule le gros fichier c'est du C :-)
EB.
[^] # Re: Première version packagée de CPS3
Posté par Eric Barroca . En réponse à la dépêche Première version packagée de CPS3. Évalué à 4.
Et vu les quelques sites importants, il est clair que ça tient la charge.
De plus Python est très utilisé dans l'industrie. c'est pas exemple language de script de CodeAster (un gros logiciel de calcul thermo-mécanique par EDF : http://www.codeaster.org(...)). Il me semble aussi que c'est utilisé par OpenCascade. Pour plus d'information la dessus tu peux consulter python.org.
Enfin, Python n'est pas fait pour être un language système à mon sens, mais un language de script de de prototypage. Dans Zope, par exemple les morceaux qui doivent aller très vite sont écrit en C et toute la partie interface et modules applicatifs en Python.
[^] # Re: Projet de refonte du site Internet de la ville de Lyon
Posté par Eric Barroca . En réponse à la dépêche Projet de refonte du site Internet de la ville de Lyon. Évalué à 2.
# Plutôt Akamai que Gnutella !
Posté par Eric Barroca . En réponse à la dépêche Open Content Network ? Un nouveau P2P libre ?. Évalué à 7.
Bref, rien a voir avec Gnutella, mais ce type de système est extrêment intéressant pour désengorger le net et distribuer le cache de façon optimale. De plus, un standard dans le domaine est le bien venu car il permettrait, dans le meilleur des mondes, de mutualiser et fédérer les systèmes de caches distribués existants et d'utiliser l'espace de stockage perdu, des utilisateurs, pour stocker le cache de l'Internet !
EB.
[^] # Re: Ministère de l'Intérieur sous Zope
Posté par Eric Barroca . En réponse à la dépêche Transfert.net parle du libre et de Zope. Évalué à 8.
Nuxeo a conçu et mis en place toute l'infrastructure de gestion de contenu du site, ainsi que la présentation automatique des résultats validés des élections (qui ont d'ailleurs entrainées un pic de charge important, permettant de démontrer la stabilité de Zope, même sous de forte charge -- techno ZEO pour le clustering).