Author: mfortun Date: 2011-06-14 16:53:07 +0200 (Tue, 14 Jun 2011) New Revision: 942 Url: http://nuiton.org/repositories/revision/wikitty/942 Log: * complete externalize solution Modified: trunk/wikitty-publication/src/site/rst/wp-externalize.rst Modified: trunk/wikitty-publication/src/site/rst/wp-externalize.rst =================================================================== --- trunk/wikitty-publication/src/site/rst/wp-externalize.rst 2011-06-10 16:05:02 UTC (rev 941) +++ trunk/wikitty-publication/src/site/rst/wp-externalize.rst 2011-06-14 14:53:07 UTC (rev 942) @@ -2,50 +2,84 @@ =============================== :Authors: Manoël Fortun - - - - but +++ -compiler les wikitty pour gagner en performance pour l'éxécution. +Le but d'externaliser les wikitty est de précompiler les wikitty pour gagner en +performance et fixer les wikittyPubText empêchant leurs modifications. +Ainsi avoir un wikitty service contenant le code applicatif "fixé" et des +wikitty service qui viennent se connecter dessus et exploiter l'application avec +les wikitty "données" que eux possèdent. +La précompilation devrait permettre plus facilement un tel fonctionnement. -Problématique de la redéfinition de wikitty comment ? -wikittypub text perdu finalement, sauf si on le récupérère depuis -un autre et on le surcharge. +Ce méchanisme sous entends qu'en plus de les précompiler on stocke les wikitty +compilé dans un jar, pour empêcher la modification. - - Un wikitty service ++++++++++++++++++ -WikittyServiceExternalize -qui sera chargé de lire le jar contenant des wikittys et tout ça. -lui qui sur un store compile et tout ? -Ca pourrait être une bonne idée ? +La première analyse envisageait une jsp qui externaliserait les wikitty, mais +finalement je pense qu'une option intéressante serait d'utiliser une nouvelle +implémentation de wikitty service. +Ce service WikittyServiceExternalize implémenterait des méthodes comme le store +de list de wikitty, restore, et les méthodes de recherche. +Le store prendrait une liste de wikitty, les écrirais sur le disque comme le +wikitty service file system, compilerais ce qui est compilable et packagerais le +tout dans un jar. +Le restore et les recherches serait des méthodes qui exploreraient le jar. +Une autre solution serait que le stockage, précompilation, packaging se fassent +par une classe un peu similaire à l'outil de synchronisation de wikitty service +mais que les restores et méthodes de recherche se fassent par une implémentation +de wikitty service sur Jar. + + Un nouveau type de wikittyPub +++++++++++++++++++++++++++++ -wikittyPubCompiled -WikittyPubStatic -wikittyPubTextCompiled +Pour que les wikitty compilés soient utilisés et éxécuté, il faut qu'ils soient +encore des wikitty, ils ne peuvent plus être considéré comme des wikittyPubText, +et on ne doit pas pouvoir les modifier. -mimetype -content en byte +Il faut un nouveau type de wikittyPub: +- wikittyPubCompiled +- WikittyPubStatic +- wikittyPubTextCompiled +Qui aurait en champ: +- nom +- mimetype (celà dit pas sur que ce soit nécessaire à la transformation du + wikitty en objet compilable celà sera peut être inséré dedans) +- content en byte + Conservation des propriétés des wikitty +++++++++++++++++++++++++++++++++++++++ +Comme pour le stockage des wikitty sur file system dans wikitty publication, +afin de pouvoir réutiliser les wikitty il faut pouvoir conserver certaines +propriété des wikitty, comme l'id, la version et eventuellement le mimeType. +Une solution serait comme pour les wikitty dans le file système de sauvegarde +les propriétés dans des fichiers de propriétés. Mais dans le minimum possible, +on aurait à la racine du jar dans un sous dossier externalIndex deux fichiers de +propriétés pour les attributs des wikitty. + +Le fait que tout soit enregistré dans seulement deux fichiers de propriétés +permet de ne pas avoir à chercher dans toute l'arborescence du jar pour +retrouver les wikitty, contrairement au cas de la synchronisation où c'était +nécessaire. + +Exemple: +-------- + + jar: +jar @@ -60,31 +94,43 @@ |||fff.class |wi.jpg +Fichiers de propriétés correspondant: +------------------------------------- - id.properties: -idwikitty=/label/unwikittyCompilé.class -idwikitty=/label/unautre.class -idwikitty=/label/chausette/autre.class -idwikitty=/label/chausette/fff.class -idwikitty=/wi.jpg +11daz5facz=/label/unwikittyCompilé.class +jbdub1dza8=/label/unautre.class +dadzadzac=/label/chausette/autre.class +dcdzcve678=/label/chausette/fff.class +oniifdefe4=/wi.jpg meta.properties -script.js.version=numéroVersion7 -scripttut.js.version=numéroVersion -image.png.version=numéroVersion -current.label=racine -script.js.checksum= checksum -scripttut.js.checksum= checksum -image.png.checksum= checksum -id.image.png=uubdazudba -id.scripttut.js=11daz5facz -id.script.js=jbdub1dza8 +11daz5facz.version=8 +jbdub1dza8.version=2 +dadzadzac.version=3 +dcdzcve678.version=1 +oniifdefe4.version=1.2 +11daz5facz.mimeType=application/javascript +jbdub1dza8.mimeType=application/jruby +dadzadzac.mimeType=application/java +dcdzcve678.mimeType=application/javascript +Es ce que finalement on ne pourrait pas négliger la version pour les +wikittyPubText externalizés? +Et considérer les wikitty comme tous de version 1.0 et donc ne plus avoir besoin +de sauvegarder dans un second fichier de propriété. +Dans le cas où l'on externalize des wikittyPubData on conserverait la version +ausi, bien que la question pourrait se poser aussi, puisque si ce wikitty +est déja existant dans le wikitty service appelant on pourrait considérer +que le wikitty externalizé est redéfini par celui du service. +Mechanisme de transformation +++++++++++++++++++++++++++++ - +Le mechanisme de transformation d'un wikittyPubText en wikitty externalizé +implique de décorer le code du wikittyPubText par du code java pour le compiler +et le stocker sous forme de classe.