:date: 11 juin 2012

documents de présentation 

- `tiramisu/report` : rapport autmatique sur une config
- `doc/buid` : doc technique (et api epydoc)
- `doc/eole-report/proposal` : diaporama
- `doc/eole-report/eolreprot` : diff creole ~ tiramisu

:date: 20 janvier 2012

créer une variable implicite cachée

:: 

    <variable name="toto"

    exists='False' hidden='True'>
    <value>non<value>

si la variable n'existe pas, elle est crée avec une valeur par défaut

cela permet une alternative aux dépendances (pour ne pas installer un 
paquet inutilement)

coder ça exactement comme les hidden ou les disabled, avec une levée 
d'exception supplémentaire comme filtre.

:date: 20 janvier 2012

coder un cache pour les options dont le propriétaire est "auto" ou "fill"
mettre ça dans un attribut `_cache` de l'option 

mettre une contrainte de temps dans le cache

- pouvoir forcer le recalcul de toutes les variables (vider le cache)
  globalement dans toute la config

- mettre une contrainte de temps donnée 
  expires = timestamp + deltatime

:date: 17 avril

- lever une exception parlante (pour l'instant, c'est une "KeyError") 
  lorsqu'on essaye d'affecter quelque chose
  à un groupe, genre

::

    cfg = Config(descr)
    cfg.gc = "uvw"

alors que gc est un groupe

:date: 12 avril

- faire un mode dégradé avec des warnings
- validations de longueur des maitres/esclaves ailleurs à sortir des requires
  et à mettre dans des validators
  
:date: 3 avril 2012

- hide sur les sous-sous groupe : il faut que ça hide **tout** les sous-groupe
  récursivement
  
groupes `master/slaves`:

    faut-il coder les multi avec des requires, ou bien simplement 
    un groupe avec comme variable le nom du groupe ?

auto, fill, obligatoire

2012-03-22

    **groupe master**
        
        faire une api du genre : `Option().is_master()`
        pour cela, tester `if self.parent._name == self._name: return True`

- mettre un attribut `auto` aux options de configuration, de manière à 
  ce qu'elles sachent quelle fonction eos appeler (que ça soit une info 
  dans l'option ou bien au niveau de la config ?)
  le fait de détecter un "auto" vient du owner, mais il faut savoir 
  quelle fonction appeler

A documenter
-------------

- les variables multiples
- expliquer les urls du json dans la doc
- documenter le typage des options descriptions descr_type 

A ajouter
---------  

Option -> attribut help (en plus de doc)
          get_help() (à mettre en class Type avec Doc aussi)
          
separator -> pas pour l'instant

fill, auto, obligatoire

nouveau type : 

type option (dérivé de ChoiceOPtion) dans lequel il y a des nouvelles valeurs
possibles (pas de validations) ou plutôt une StringOption qui propose un choix
de valeurs par défault de type liste.

:date: 24 mars

- hide pour les sous-sous config (récursivement) et pas seulement une 
  seule sous-config (ou bien, quelque chose de réglable)

- validate global : vérifier à l'init de la conf qu'une variable 
  n'existe pas déjà, etc

:date: 26 janvier

- un attribut eosfunc pour auto + les paramètres à donner à la fonction
  pareil pour le fill (function et paramètres)

reset
-------

**à discuter** : ça correspond exactement au override, 
ou bien au opt.setoption(None, 'default')

**si la valeur par défaut est définie, un __get__ ne pourra jamais 
renvoyer None.** ce qui est bloquant. Il faut pouvoir revenir à None.

pour supprimer la valeur d'une options (et revenir à la valeur par défault)
cfg.reset() (supprime _cfgimpl_value[name]) et _cfgimpl_value_owner[name])

reset()