[AlternC-dev] alternc2.0 : architecture ??

Retour à l'archive de la liste
Le site d'AlternC
Google Custom Search

Lunar lunar at anargeek.net
Jeu 7 Déc 22:48:38 CET 2006


Le jeudi 07 décembre à 20:15 +0100, Nahuel ANGELINETTI écrivait:
> Le système de convergence peut etre pas mal, mais prend le controle sur
> tout le système et va pas arreter d'hurler si il y a la moindre
> modification faite à la main.

Sur ce point là précis, ça peut être « pire », ça dépend à quel point le
daemon à envie de voir le système converger... Il peut par exemple
détruire tout ce qui ne se trouve pas dans son modèle.

En même temps, l'AlternC actuel, avec son fonctionnement hybride, je
l'ai déjà vu bousiller des données en écrasant des fichiers... uu en
supprimant des trucs sans qu'on lui demande vraiment...

Pour ce qui est de la cohérence du modèle, c'est possible de faire du
calcul symbolique dessus. Ou c'est même possible d'utiliser un bon
moteur de données qui sait faire des calculs d'intégrité et de
contrainte. Suffit de voir quels tests ça représente, hein. Pour moi,
c'est juste des trucs du style « une boite mail appartient à un domaine
qui existe bien ».

Attention toutefois, si une architecture orienté « convergence »
est retenue, je pense qu'il ne faut pas refaire la même
erreur que celle qui existe dans AlternC actuel : les données utilisés
par Postfix (par exemple) ne sont directement celle du modèle. Il doit
exister une étape intermédiaire entre les deux.

Si une architecture « batch » est retenue, il y a un point sur lequel il
faut réfléchir : comment s'assurer de la cohérence de la file de
requête à traiter (par rapport à l'état du système [1] et par rapport
aux requêtes entre elles) ? À quel point cette file sera « sûre » (vis à
vis d'un arrêt du système par exemple, ou d'une défaillance
temporaire) ? Et bien entendu, comment seront visuellement représentés
les requêtes, et leurs éventuelles erreurs ? 

Allez, je peux conclure avec quelques questions supplémentaires sur le
dernier type d'architecture évoquée (appelée « live ») : comment
s'assurer de la cohérence entre les données sur l'état que devrait avoir
le système et la base qui référence ce qu'il contient ? Que faire en cas
d'arrêt au milieu d'une opération ? Que faire lorsqu'un des outils
nécessaires est dans un état inattendu [2] ?

Je pense que c'est des questions très importantes. Et qu'il est
nécessaire de réfléchir là-dessus avant de vouloir écrire une API ou
même du code. Sans quelques principes *clairs* et *cohérent* sur comment
le système est censé se comporter dans son ensemble, je vois pas le cas
où ça ferait pas de la bouillie pénible d'ici quelques mois...

[1] J'inclus dans ce dernier une éventuelle base « d'accounting ».
    Je ne veux pas l'appeler « modèle » parce que ça n'en sera pas un :
    il sera impossible de recréer l'état du système (à partir de ce
    dernier).
[2] Genre un serveur mail qui est arrêté au moment où un mail doit être
    envoyé.

À peluche,
-- 
Lunar                                               http://anargeek.net/
                      ·-|-·hack your mind·-|-·
                                               weather: Scattered clouds
Dijon                                             temp: 7.0 C
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: signature.asc
Type: application/pgp-signature
Taille: 189 octets
Desc: Digital signature
URL: <http://lists.alternc.org/arch/dev/attachments/20061207/8fcaef21/attachment.pgp>


Plus d'informations sur la liste de diffusion Dev