L’interface sylabe, comme tout programme, permet une certaine personnalisation et quelques restrictions d’usage par le biais d’options. Ces options sont pour l’instant stockés dans un fichier unique dédié aux options de nebule et potentiellement tout programme qui en a besoin, comme sylabe.
Ce fichier est a créer à côté du bootstrap. Et il restera en place pour nebule afin de forcer certaines options sans possibilité de les changer. Évidement, ce forçage des options par un fichier ne vaut que si le fichier n’est pas modifiable, au moins de façon trivial. Par contre, il n’y a pas de raison raisonnable de conserver un forçage des options de sylabe.
Il est préférable de s’orienter vers des options manipulées comme des objets. C’est à dire que chaque option de configuration sera un objet dédié avec un lien vers l’objet contenant la valeur de l’option. Cela ralenti un peu le chargement d’une option puisque ses liens doivent être vérifiés, ce qui n’est pas un mal. Mais cela va aussi permettre de générer les options sur une machine, c’est à dire sous une entité A, et de les attribuer à une autre machine, c’est à dire une entité B. Bien sûr, cette attribution et surtout cette reconnaissance d’une option se fera par rapport à la validité sociale des liens. Et dans ce genre de cas, on ne reconnaît les liens que de peu d’entités.
Ces options seront par défaut protégées. Même si on se doute de certaines (true/false), d’autres ont tout intérêt à être cachées. Elle pourront éventuellement être offusquées si on ne souhaite pas montrer l’usage de certains modules de sylabe. Et comme il peut être facile de déduire la valeur de certaines options dans un temps raisonnable, notamment par le lien de chiffrement, chaque objet contenant une valeur d’une option devra aussi contenir une partie non utilisée avec de l’aléa. Ainsi, l’objet chiffré sera lié à un objet en clair, supprimé, mais ne permettant pas de déduire la valeur de l’option.
Il est aussi possible de le faire par des liens offusqués, à voir…