bitobi-arch
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bitobi-arch] Prerequis.


From: Estian
Subject: Re: [Bitobi-arch] Prerequis.
Date: Thu, 26 Dec 2002 20:01:31 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aurélien DEHAY wrote:

| Bonjour a tous.
|
| Pour commencer correctement, pourquoi ne pas fixer quelques uns des
| prerequis necessaires a la realisation de bitobi?
|
| Je pense que nous en avions deja poser quelques uns sur le wiki de
| nostromo<, mais un rappel et une mise au point la dessus ferais pas de
| mal. Donc:
|
| 1) Garder la compatibilite coincoins.
| 2) et...
|
Je plussoie, et je me lance

Pour la compatibilité coin², ça veut donc dire du XML selon la DTD
templeet.C'est très bien, et à mon sens ça nous suggère de travailler au
maximum en XML en interne, quitte à jouer un peu du XSLT pour mettre les
choses au carré. Je suggererais néanmoins d'essayer de remplacer la DTD
(puxor) par un xml-schemas (roxor), et au passage de bien importer les
entités html, ou xhtml maintenant, ce qui permetrait éventuellement de
se passer de rendu HTML : la page XML, publiée avec une feuille XSL
kivabien, pourrait être visionnée directement dans le navigateur (et
hop, une étape de moins). Et un xsl plus tard, on pourrait faire un
rendu mobile-friendly.
Puisqu'on part sur une première implémentation en Rubis, je suggère
également qu'on mette en zoulis diagramme le fonctionnement du bidule,
et d'organiser le tout en couches bien modulaires.. à la louche, je
verrais une couche réseau gérant les flux inter-bitobi, une couche
traitant les messages reçus et les dispatchant vers les autres bitobi si
besoin est, ou vers le traitement 'interne', une couche de stockage des
données en local (que je verrais bien interchangeable, pour pouvoir
stocker à volonter dans du sql, un fichier plat, ...), une couche pleine
de xml pour le rendu, et une couche http (ou une interface vers un http
existant, réduite peut-être à la génération d'un fichier dans le
répertoire kivabien). J'oubliais un module s'interfaçant à priori au
niveau de la couche 'traitement', mais peut-être aussi dès la couche
'réseau', comprenant les routines GPG et gérant donc les
authentifications des bitobi, et j'imagine des administrateurs.

Voilà, j'ai probablement oublié des éléments, mais ça devrait donner une
première base de travail. Pour les zoulis diagrammes, êtes vous pour ou
contre l'utilisation d'un formalisme à la UML? Et sinon, qu'est ce qui
vous paraitrait adapté?

Vincent
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+C1IK5didzvdbnrURAhmHAKCkyf9lVBhpx+sgoTxuist1kccvVQCfRFEX
fCNcXf0F81JwE4GM49xQ54U=
=a95L
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]