TODO

   1 * Use of data on the stack as argument to MsgNew does not work
   2 * Warn when using a server socket to write, or a client one to poll
   3
   4 * while (1) { fork; exec the child, wait in father }
   5 * message forwarding
   6
   7 [autoconf]
   8   Check in autoconf that no datatype is bigger than 64, or dynar_map will
   9     get into trouble...
  10
  11 [portability layer]
  12   Make a script to test how the padding bytes are on the current arch, and
  13    constitute a bestiary.
  14   Use Arnaud's structure parser in a macro
  15   Dynar of type, such as ref of type
  16   Generate convertors in assembler ?
  17   Mallocators
  18
  19 [Messaging]
  20   Message forwarding
  21   Message priority
  22   Messages in a tree manner
  23
  24 [network drivers]
  25   Interface: open_server, open_client, read, write, flush, close
  26   Implementations: TCP, SG (more after my PhD).
  27
  28 [errors]
  29   Better split casual errors from programing errors.
  30     The first ones should be repported to the user, the second should kill
  31     the program (or, yet better, only the msg handler)
  32   Allows the use of an error handler depending on the current module (ie,
  33    the same philosophy than log4c using GSL's error functions)
  34   Rethink the error codes. Source of inspirations are:
  35    - comerr (common error reporting from ext2)
  36    - libgpg-error
  37
  38 [logs]
  39   Parse argv (check leonie and tbx_arg_iterator in tbx_parameter.h)
  40   Several appenders; fix the setting stuff to change the appender
  41   Hijack message from a given category to another for a while (to mask
  42     initializations)
  43
  44 [dict]
  45   Make a real container for the dict, so that the free function may be given
  46     only once for the whole tree (would help to send dicts).
  47   dichotomie in search
  48   speed up the cursors, for example using the contexts when available
  49   fix multi levels dicts
  50
  51 *********
  52 * GRAS1 * Integrer grassouillet a gras; multiplexage XML; module de comm
  53 *********
  54 [type_bag SG]
  55  un peu comme les type_bag RL, mais sans tenir compte d'incoming ni
  56    outcoming.
  57  La finesse est de simuler la taille des envois sans les faire
  58  On peut aussi imaginer une version faisant ces envois effectivement, qui
  59    serait un peu plus lente, mais permettant de debugger cette partie de
  60    grassouillet
  61
  62 [pilotes reseaux de sous grassouillet]
  63  TCP: utilise le fd. rien a faire.
  64  SG: Le send fait le boulot de malloc du recv de fd, et les rempli comme le
  65    send de fd.
  66  BLOC: Un nouveau truc, qui envoi des trames les unes derriere les autres,
  67    un write copie dans un buffer qui, quand il est plein, part sur la socket
  68    avec sa taille devant, et son CRC derriere.
  69   C'est le prix a payer pour ne plus mourrir si vite en cas de transmission
  70    pourrie (mais ca resoud tjs pas le pb du code malicieux)
  71   Possibilite de compresser les buffers avant l'envoi..
  72
  73 [simuler le select sur les sockets avec des threads]
  74   Le plan, c'est qu'a l'ouverture d'une socket server, on cree un thread
  75     charge de faire du pool blocant dessus, et des que ce thread se debloque
  76     car il commence a lire qqch, il passe la main a un thread de
  77     communication charge de faire la lecture.
  78   Quand la lecture est finie, le thread de comm passe la main aux threads
  79     d'execution (un par couleur).
  80
  81   Voici comment faire le coeur du truc [dixit Olivier]:
  82     Une liste est utilisee pour stocker ce que le thread de comm a le droit
  83       de lire. Elle est protegee par mutex pour eviter les acces concurents.
  84       c'est la "liste de lecture"
  85     Une semaphore "de lecture" est utilisee pour permettre aux threads
  86       servants des sockets de prevenir le thread de comm qu'ils ont qqch
  87       pour lui
  88     Dans la liste de lecture, on place les messages en cours de creation, et
  89       un ptit mutex pour que le thread de comm dise aux threads servants de
  90       retourner ecouter la socket car il a fini
  91     Chaque couleur a sa file de callback a appeller, proteger par semaphore
  92       et un mutex comme pour la file de lecture
  93
  94     Init:
  95      initialisation de toutes les semaphore a 0
  96      comm: sem_P(semaphore lecture)
  97      couleur: sem_P(semaphore de la couleur correspondante)
  98      servant: read (1) sur la socket
  99
 100     Arrive d'un message
 101      servant:
 102      1) le read debloque (c'est la version de gras, utilisee pour multiplexe
 103         sur le XML, ou sur les differentes versions de gras/de pilote reseau)
 104      2) Allocation du message vide pour contenir ce qui s'annonce
 105      3) initialisation du mutex du message_instance a 0 (verrouille)
 106      4) placement du message instance dans la file (prise de mutex,
 107         placement, lachage de mutex)
 108      5) sem_V(sempahore)
 109      6) mutex_lock sur le mutex_verrouille
 110      sleep
 111      7) quand on revient, on rebloque un read(1), et on recommence
 112
 113      comm:
 114      1) on se reveille quand la semaphore se libere (etape 6 des servants)
 115      2) prise d'une tache dans la file (protegee par semaphore)
 116      3) lecture de l'instance de message
 117      4) lache le mutex dans l'instance pour liberer le servant
 118      5) pose le message pret dans la file de la couleur correpondant au
 119         premier callback de la pile pour ces {messageID x version} et
 120         augmente le semaphore correspondant.
 121      6) se rebloque sur le semaphore de lecture et recommence
 122
 123      couleur:
 124      1) on se reveille quand quelqu'un a pose qqch dans sa file des messages
 125         prets
 126      2) on le retire de la file
 127      3) on acquiere le mutex d'execution de sa couleur (pour les callbacks
 128         cameleon)
 129      4) on execute le callback qu'il faut
 130      5) on lache le mutex de sa couleur
 131      Si le callback annonce avoir mange le message
 132        a) on libere le message (le payload doit avoir ete libere par
 133           l'utilisateur)
 134        b) on decremente le TTL du callback, et on le vire si c'etait pas un
 135           callback infini et qu'il arrive en fin de vie
 136      Sinon
 137        a) on place le message dans la liste des messages de la couleur du
 138           suivant dans la pile des callback
 139      6) On se rendort sur le semaphore de sa couleur et recommence
 140
 141     Emission d'un message:
 142      A faire. Le thread de comm peut faire ceci, ou on peut faire un nouveau
 143       thread de comm pour cela.
 144
 145     Fermeture d'une socket client:
 146      Probleme: faut tuer le thread servant.
 147      Solution pour l'instant: fermer la socket depuis ailleurs.
 148      Solution si ca marche pas (ou pas partout): Les servants font des
 149       selects sur un pool {leur socket x un pipe fait pour}
 150       Quand qqch arrive sur le pipe, c'est le signal du suicide.
 151
 152 [Conversions inter-architectures]
 153  Marquer les padding bytes explicitement aux structures (juste le sizeof
 154    doit suffire)
 155  Marquer les offsetof des fields explicitement a l'ajout.
 156  Prevoir tous les encoding pour les types elementaires
 157    [taille, sexe, signess[non, a un, a deux]]
 158    plus les flotants, justifiant un traitement a part
 159  Tester avec autoconf les encodings sur l'archi courante
 160  Trouver un moyen de convertir un encoding en un autre (si possible par
 161    blocs)
 162  Generer ces convertors en assembleur a chaud, puisqu'on a rien de mieux a
 163    foutre de notre temps
 164
 165 [XML]
 166  Tout comme c'est dit dans les articles
 167
 168 [Macro parseuse]
 169  Gerer les typedefs (necessite de l'aide de grassouillet)
 170  Gerer les pointeurs.
 171    Faut des annotations pour dire si c'est :
 172     - un AZT
 173     - un tableau dont la longueur est ailleurs dans la struct
 174     - une ref
 175    Ca peut se faire soit avec des commentaires, soit avec des macros se
 176      reecrivant a rien dans la vraie vie, et parsee. Mais le risque est que
 177      ces macros soient reecrites avant d'etre passee a mon bordel, selon les
 178      cpp.
 179  Gerer les unions => specifier des annotations, mais j'y crois pas
 180  Gerer les enum
 181  Gerer les long long
 182  Gerer les types struct, union et enum anonymes au milieu d'un autre bloc de
 183   donnees.
 184  Verifier que "char"="signed char" sur toutes les archis
 185
 186  Renomer gs_parse_tok_num en gs_parse_token
 187  Check short a, b;
 188  Check short ***
 189  Check struct { struct { int a } b; }
 190
 191 [Grassouillet]
 192  Gerer les typedefs pour aliaser un type sur un autre
 193  Merger gs_type_union_append_field et gs_type_struc_append_field si possible.
 194  Gerer les enum ?
 195  gs_type_copy/gs_type_free
 196  A quoi sert le champ name de gs_type_struct_append_field ?
 197  Ca plante bizarement si on met une structure n'existant pas dans le
 198    message (a l'usage)
 199  gs_type_dump, nardin, comment voir ce qui se passe sinon ??
 200
 201 [Autres]
 202  Simplifier l'API pour virer les sequences
 203  Faire le parseur automatique de structures
 204  Faire toutes les modifs aux Utils listees plus haut
 205  Simplifier l'envoi de dynar et dico
 206  Mettre les mutex et semaphores dans les dynar directement
 207  Tenter (politiquement) le passage a GPL, pour voler du code.
 208
 209
 210 ************
 211 * La suite *
 212 ************
 213 GRAS double (ou encore "GRAS too" ou "too GRAS"):
 214  - Priorite des messages
 215  - Outils de visu pour ce qui se passe dans le simulo
 216  - Outils de visu/deployement/management pour RL
 217
 218 GRAS (très):
 219  - outils mathematiques pour dire des choses sur la validite du protocole
 220