Ideas / TODO:
-* Hacer el protocolo completamente introspectivo, de manera que el cliente pueda
- ser muy simple y genérico y en caso de agregar funcionalidad no sea necesario
- modificarlo.
+* Agregar soporte de opciones de línea de comando/archivo de conf para:
+ * Dry run.
+ * Seleccionar servicios a usar.
+ * Puerto/bind addr.
+ * Logging.
+ * Paths.
-* Evaluar hacer un RootHandler en vez de un diccionario con los handlers de la
- raiz para simplificar la introspección y tener un help/commands global.
-
-* Evaluar que el dispatcher vea si se llama a un HandlerContainer y de ser así
- que tire una ayuda en vez de un CommandNotFound (por ejemplo si se pone:
- "dhcp" solo que tire una ayuda). Y si hay un subcomando no encontrado, que
- tire un Command Not Found in handler (por ej "dhcp lala" -> Command "lala" not
- found in "dhcp").
+* SubHandlers:
+ * Agregar SetSubHandler? (para Proxy Hosts)
* Agregar logging.
* Agregar validación con formencode.
-Estas cosas quedan sujetas a necesitada y a definición del protocolo.
-Para mí lo ideal es que el protocolo de red sea igual que la consola del
-usuario, porque después de todo no va a ser más que eso, mandar comanditos.
+* Hacer que el estado sobre si un servicio está andando o no sea más confiable
+ que un simple flag interno (en caso de ver que realmente esté corriendo,
+ probablemente sea una buena idea que haya un flag que indique si hay que
+ levantarlo en el inicio).
-Por otro lado, el cliente de consola, por que no es el cliente web pero
-accedido via ssh usando un navegador de texto como w3m???
+* No usar comandos con templates, porque después si no hay que ejecutarlos con
+ un shell (porque el template devuelve un string todo grande) y hay que andar
+ teniendo cuidado de escapar las cosas (y hay riesgos de seguridad de shell
+ injection).