- Simexplorer-si-devel - mailman.cloud.codelutin.com

Publication RC 1
by landais＠codelutin.com April 11, 2008

April 11, 2008

Bonjour, une version RC1 est disponible sur le labs : <https://labs.libre-entreprise.org/frs/?group_id=130>. Il est préférable de supprimer le dossier /var/local/simexplorer avant d'exécuter cette nouvelle version. Aussi, il faut supprimer l'ancien EAR dans le dossier deploy de JBoss. Pour lancer le module Swing, il suffit de lancer le go.sh. Une fenêtre doit apparaître vous demandant les paramètres de l'application. On notera surtout l'adresse du serveur ainsi que le login utilisé. Le mot de passe étant sauvé hashé, on ne peut pas le saisir directement dans la fenêtre de préférences. N'hésitez pas à répondre pour tout problème. Cordialement, Gabriel

3 12

CR Réunion 08/02/2008
by landais＠codelutin.com Feb. 27, 2008

Feb. 27, 2008

Bonjour, suite à la réunion d'hier, voici les éléments qui ont été abordés : Général - Mettre à jour les entêtes de fichier avec une licence GPL incluant en auteurs Cemagref, Code Lutin et les développeurs ayant participé au projet - Decouper les métadonnées en deux parties : celles propres à SimExplorer et celles propres au SI. - Refondre les entités afin de les générer depuis un modèle et gérer la sérialisation par outils comme JAXB/XStream, ceci dans un module propre (et non inclu avec les autres classes storage) Serveur - Suppression : La règle de gestion "suppression d'un CE/DE entraîne la suppression de l'AE (si elle est la seule à l'utiliser)" n'est pas correctement implémentée (suppression récursive de tous les parents si ils sont les seul à utiliser l'élément) - Vérification d'existence de l'élément dans la base : si les hash sont égaux, vérifier que les données sont effectivement égales - Filtrage des listes en fonction des droits (implémentation d'un Filter Lucene, conservation de l'indépendance du stockage et de la sécurité) - Paginer la recherche des éléments dont l'utilisateur est propriétaire - Gestion du tri sur toutes les colonnes pour les recherches - Créer les interfaces accessibles via d'autres protocoles que RMI (WebService, CORBA). - Remplacer l'invoker jrmp par http afin de permettre l'utilisation de proxy (voir http://www.jtips.info/index.php?title=JBoss/HttpInvoker et http.proxyHost, http.proxyPort, proxySet, http.proxy.username et http.proxy.password) Interface web - Ecran de gestion des droits sur tous les éléments Interface Swing - Créer des méthodes afin de permettre à SimExplorer d'utiliser le SI comme Documentation - Documentation utilisateur - Enoncer les règles métiers qui ont été développées dans un document indépendant du code (pas du Javadoc) - Documentation développeur - Documentation intégration (backup, dumps, configuration) Je renverrais des mails sur certains points abordés, afin de valider/préciser le besoin. Cordialement, -- Gabriel <landais at codelutin.com> http://www.codelutin.com tel : 02 40 50 29 28 / fax : 09 59 92 29 28

2 2

mise à disposition de la documentation de simexplorer-si
by chemit＠codelutin.com Feb. 19, 2008

Feb. 19, 2008

Les premières documentationssont désormais accéssibles à l'adresse suivante : http://simexplorer-si.labs.libre-entreprise.org Cordialement, Tony.

1 0

Réunion de travail
by landais＠codelutin.com Feb. 12, 2008

Feb. 12, 2008

Bonjour, avec Benjamin nous avons pensé qu'il serait opportun de s'organiser une réunion en parallèle de Mexico la semaine prochaine. Je profiterais du fait que Benjamin soit sur Clermont pour vous rencontrer et discuter du projet. Nous pourrons ainsi finaliser les interfaces de visu et spécifier les interactions avec SimExplorer. Si ce n'est pas envisageable, merci de me tenir au courant. PS : j'ai changé la règle de réponse à un mail de la liste, le destinataire étant automatiquement la liste lorsque l'on répond, plutôt que l'expéditeur. Cordialement, -- Gabriel <landais at codelutin.com> http://www.codelutin.com tel : 02 40 50 29 28 / fax : 09 59 92 29 28

1 0

Prototype
by landais＠codelutin.com Feb. 12, 2008

Feb. 12, 2008

Bonjour, vous trouverez une première version du prototype via ce lien : <http://labs.libre-entreprise.org/frs/?group_id=130> L'installation est documenté avec le fichier ci-joint, qui sera à terme intégré dans le site hébergé sur le labs. Les choses non finalisées sont listées dans le fichier todo.rst joint lui aussi. La livraison concerne uniquement la partie web. Cordialement, Gabriel -------------- section suivante -------------- Un texte encapsulé et encodé dans un jeu de caractères inconnu a été nettoyé... Nom : install.rst Url : https://lists.labs.libre-entreprise.org/mailman/private/simexplorer-si-deve… -------------- section suivante -------------- Un texte encapsulé et encodé dans un jeu de caractères inconnu a été nettoyé... Nom : todo.rst Url : https://lists.labs.libre-entreprise.org/mailman/private/simexplorer-si-deve…

2 8

Livraisons
by landais＠codelutin.com Jan. 30, 2008

Jan. 30, 2008

Bonjour, nous voilà tout près de livrer une première version prototype. Je souhaitais voir avec vous quels moyens nous utilisons pour les livraisons. Dans un premier temps, je pense vous fournir l'EAR de l'application web, avec un guide d'installation basique (où mettre l'archive, lancer l'application, premier login). Il devra ainsi être mis en place un serveur avec un JBoss, de préférence en intranet afin de ne pas ouvrir l'application à l'extérieur. Est ce que cela vous convient? De plus, le delivery sera géré via le labs Libre Entreprise, où l'on peut déjà trouver le code source. Cordialement, Landais Gabriel

2 3

Choix moteur base de données
by landais＠codelutin.com Dec. 17, 2007

Dec. 17, 2007

Bonjour, après avoir reconsidéré les besoins et les fonctions nécessaires à l'indexation et la recherche d'éléments, nous avons pensé utiliser Lucene pour l'implantation de la base de donnée. Les données ont été décomposées en trois groupes : * les meta-données de chaque élément, permettant de l'identifier, de connaître son type, son parent en version, etc * le contenu indexé, provenant d'une librairie, de résultat, etc. C'est sur ce contenu que la recherche full text sera faite * les données à proprement parler, qui sont stockées sur le système de fichier. On conserve dans ces fichiers les meta données, afin de permettre la reconstruction d'une base à partir d'un dossier. Lucene fonctionne par document indexé. Chaque document a des champs, associant à un libellé une valeur. Cette valeur peut être indexée et/ou stockée. Un document peut avoir plusieurs champs avec le même nom. Nous stockons ainsi les meta données dans des champs prédéfinis, et le contenu à indexer dans un champ non stocké. Une fois les documents indexés, la recherche peut se faire sur des champs de meta donnée afin de récuperer un élément en particulier, ou sur le champ indexé. Cette dernière recherche permet des requêtes textuelles complexes, en autorisant les jokers, les opérateurs booléens, etc. Afin de valider ce choix, nous avons procédé à différents tests, notamment de montée en charge. Ainsi, un test a créé une base de 25 000 documents, contenant chacun entre 10 000 et 30 000 mots d'un dictionnaire de 150 000 mots (entre 2 et 7 lettres). Soit au total environ 11Gb de données indexées. L'index en lui même pèse 3Gb, le contenu n'étant pas stocké. L'ajout atomique de document et la recherche ne pose pas de problème de performance, Lucene étant suffisamment mature et la transformation entre un document et des méta données simple. La principale difficulté se trouvent dans la gestion des fichiers d'index. Une fois que ceux ci sont ouvert en lecture, Lucene conserve un index correspondant au lecteur au moment de son ouverture, tout en laissant la possibilité de continuer l'indexation. Afin de conserver la cohérence entre ce qui est lu et ce qui est écrit, le lecteur est invalidé lors de l'écriture de données. Lors de la première lecture après une écriture, une ouverture d'un nouvel index est réalisé, et est pratiquement immédiat. Les recherches full texte sur deux caractères (type eu*) sont assez rapides (150 à 200ms), le plus long étant la récupération des document depuis l'index, en récupérant tous ses champs associés (3ms par document). Un avantage majeur de Lucene est aussi son aspect portable, il peut être exécuter sur le poste client ou sur le serveur sans problème. L'implantation du moteur Lucene se base sur l'interface Database ci jointe. Ainsi, si vous n'y voyez pas d'objection, Lucene sera utilisé pour stocker les meta données. Cordialement, Gabriel -------------- section suivante -------------- Une pièce jointe non texte a été nettoyée... Nom: fr_cemagref_simexplorer_is_storage_database_classes.png Type: image/png Taille: 4887 octets Desc: non disponible Url: https://lists.labs.libre-entreprise.org/mailman/private/simexplorer-si-deve…

2 3

Questions
by landais＠codelutin.com Dec. 12, 2007

Dec. 12, 2007

Bonjour, tout d'abord merci pour vos réponses, cela me permet de bien avancer. Savez vous déjà quel sera le format physique utilisé afin d'échanger des données? Il doit contenir dans un premier temps un fichier XML. A l'intérieur de celui-ci, on doit trouver les meta données (attributs du "LoggableElement") ainsi que les données (constantes, valeurs, codes, etc). De plus, ce fichier peut être une librairie avec un fichier attaché binaire, ou une application d'exploration avec des données d'exploration pouvant contenir un résultat sous forme de zip. On peut ainsi se retrouver avec un fichier devant contenir plusieurs zip avec plusieurs données d'exploration. IMHO, il faudrait définir une structure de fichier afin d'être en mesure d'associer un élément xml à un fichier, du type : MyExplorationApplication.zip +--data.xml x--<metadata> x--<id> x--1 x--<version> x--2 x--... x--<ed> x--<result> x--attach1.zip x--... x--<ed> x--<result> x--attach2.zip x--... x--<c> x--... +--attachments +--attach1.zip +--attach2.zip Les metadata peuvent être séparées du data.xml, en ayant leur propre fichier (notamment pour obtenir un checksum sur les données uniquement). Pour le moment ce que j'ai fait est assez générique, j'aurais besoin de ces éléments assez rapidement pour continuer. Aussi, le schéma du fichier xml doit être partagé avec SimExplorer, qui le produit et lequel fait référence? Enfin, l'application sera la plus tolérante possible sur la pertinence des meta données envoyées, mais les informations sur le parent en version ou en données devront être régies par des règles de gestion à définir précisément et à implanter dans SimExplorer. Merci! Gabriel

2 1

Questions
by landais＠codelutin.com Dec. 7, 2007

Dec. 7, 2007

Bonjour, voici quelques questions : - Quel nom de package doit on utiliser? Je suis parti sur org.cemagref.simexplorer.si pour le moment. - Il est difficile de garantir qu'un contributeur conserve le droit de lecture/écriture si le propriétaire change. Ne serait-il pas préférable d'avoir plusieurs propriétaires pour un seul élément? - Comment gérer la perte de permission de lecture d'un composant par un utilisateur alors qu'il l'utilise dans une de ses explorations? Est ce qu'un utilisateur a toujours la possibilité de lire tous les sous-éléments des éléments dont il est le propriétaire? - Afin de garantir la synchronisation entre le client et le serveur, les identifiants des éléments doivent être unique, dans tous les contextes où ils sont générés. Il est indispensable pour SimExplorer-si d'affecter aux éléments des identifiants du type UUID (http://en.wikipedia.org/wiki/UUID) Est ce que c'est possible/réalisé? Merci Gabriel

2 1

CR Reunions Clermont
by landais＠codelutin.com Nov. 30, 2007

Nov. 30, 2007

Bonjour, Voici les points que j'ai relevé suite à la venue de Benjamin à Clermont. Vous trouverez quelques questions en note, pouvez vous y apporter des éléments svp? Merci - Les administrateurs ne sont pas chargés de valider les AE soumises, contrairement à ce qui avait été compris dans un premier temps. - Choix de lucene comme système de stockage des méta données et d'indexation - Le serveur n'est pas chargé de lancer de simulation. Simexplorer SI s'occuper uniquement de stocker les données d'AE * Une API permet à l'application SimExplorer de stocker ses données - Les CE et les DE ne sont jamais soumis individuellement, mais via une AE - Gestion des droits : * Les groupes ont des sous-groupes * Un utilisateur peut appartenir à plusieurs groupes * Une permission autorise un utilisateur/groupe la lecture/écriture/suppression d'un élément ainsi que la gestion des permissions de l'élément * Un élément peut avoir plusieurs permissions * Un élément possède un unique propriétaire [1] * L'utilisateur mettant à jour un élément en devient le propriétaire [1] * Toutes les versions d'un élément possède les mêmes permissions * Un utilisateur peut toujours modifier et créer des permissions sur ses éléments [2] * Un utilisateur peut toujours ajouter une nouvelle AE * Un utilisateur peut créer un sous élément à un élément uniquement si il a les droits d'écriture sur cet élément (ex : création/ajout d'un CE dans une AE) - Application web * Pas de création d'élément * Fonction d'export d'une AE * Recherche sur différents critères * Import de librairie et d'AE, par deux champs distincts * Affichage des groupes de chaque utilisateur dans la liste des utilisateurs * Affichage des éléments dont l'utilisateur est propriétaire lors de l'édition d'un utilisateur * Gestion des groupes enfants dans la page d'un groupe * Gestion des utilisateurs d'un groupe dans la page d'un groupe * Création d'une page d'administration des droits : + Filtre sur le propriétaire via un utilisateur ou un groupe (pour les administrateurs) + Affichage des éléments dont l'utilisateur est le propriétaire + Édition des droits d'un élément (entités ayant le droit de lire/écrire/administrer l'élément) - Versionnement * Chaque enregistrement incrémente la version mineure (1.4 -> 1.5) * Exceptions : + Export sur le serveur : incrémentation de la version majeure (1.5 -> 2.0), renumérotation sur le client [3] + Export sur le serveur, après l'export d'un autre utilisateur : création d'un nouvel élément, en conservant l'historique de l'élément * Export d'une AE sans parent : création d'une nouvelle AE sans historique * Un utilisateur peut créer une nouvelle version sur un élément si et seulement si il a les droits d'écriture sur cet élément * Soumission d'un élément par un utilisateur ne possédant pas les droits d'écriture (pour création d'une nouvelle version) : création d'un nouvel élément, en conservant l'historique de l'élément * Suppression d'un CE ou de DE : suppression des AE associées (avec message de confirmation...) * Suppression d'une AE : les CE et les DE orphelins (ie utilisés uniquement par cette AE) sont supprimés * Un utilisateur soumet une AE : + L'AE contient un CE qui devrait être soumis dans une nouvelle version (composant partagé par plusieurs AE) + L'utilisateur n'a pas les droits d'écriture pour ce CE sur le serveur + -> un nouveau CE est créé et associé à cette AE [1] Difficile de garantir qu'un contributeur conserve le droit de lecture/écriture si le propriétaire change. Ne serait-il pas préférable d'avoir plusieurs propriétaires pour un seul élément? [2] Comment gérer la perte de permission de lecture d'un CE par un utilisateur alors qu'il l'utilise dans une de ses AE? Est ce qu'un utilisateur a toujours la possibilité de lire tous les sous-éléments des éléments dont il est le propriétaire? [3] Afin de garantir la synchronisation entre le client et le serveur, les identifiants des éléments doivent être unique, dans tous les contextes où ils sont générés. Il est indispensable pour SimExplorer-si d'affecter aux éléments des identifiants du type UUID (http://en.wikipedia.org/wiki/UUID) NB AE : application d'exploration DE : données d'exploration CE : composant d'exploration Bon week end, Gabriel

1 0