Inicio / TLS / Filosofía

Las 14 Leyes

Estas reglas rigen cada decisión, cada línea de código y cada module. Son innegociables. El núcleo es la base — no se cambia la base, se construye sobre ella.

Reglas absolutas. Estas leyes se aplican a cada instancia, cada module, cada colaborador. No son directrices — son la constitución del sistema.

1. Todo es un path

Cada recurso, servicio, dispositivo, API, fichero o acción se accede a través de un path. Un path es la dirección universal. Sin excepciones.

/node/module/resource
/local/serial/com1/read
/local/web/api/v1/users
/remote-dc1/db/postgres/query
/local/auth/login

Si existe, tiene un path. Si tiene un path, se puede alcanzar.

2. Todo es un mensaje

Toda la comunicación fluye a través de una única estructura: el Message. Petición, respuesta, evento, notificación — todo son mensajes.

Un mensaje tiene: un path, un method, headers, un body y un contexto. Nada se comunica fuera de esta estructura. Sin puertas traseras, sin atajos.

3. El núcleo no hace nada

El núcleo es un router, un cargador y un árbitro. No implementa lógica de negocio. Enruta mensajes, carga módulos, aplica control de acceso y traza la ejecución.

Toda la funcionalidad reside en los módulos. Un servidor web es un module. Un conector de base de datos es un module. Un lector RS232 es un module. Un proveedor de autenticación es un module.

El núcleo sin módulos está en silencio. Eso es correcto.

4. Sin dependencias rígidas

Si el module A necesita al module B y B no está cargado, A no falla catastróficamente. A recibe una respuesta limpia de «no disponible» y decide qué hacer.

Toda dependencia es blanda. Toda ausencia es elegante. Un module debe estar diseñado para funcionar en modo degradado, no para exigir perfección.

5. Hot-load para todo

Los módulos se cargan, descargan y recargan en tiempo de ejecución sin detener el núcleo. El sistema nunca se detiene. Las piezas van y vienen. El núcleo perdura.

portal:/> module load web
portal:/> module reload iot
portal:/> module unload mqtt

6. Una interfaz, universal

Un module que lee RS232 habla el mismo idioma que un module que sirve HTTP. La estructura de mensaje es la lingua franca. Apréndela una vez, construye cualquier cosa.

Un module de interfaz web puede consultar un module de puerto serie usando el mismo mecanismo que utiliza para consultar un module de base de datos. Sin adaptadores, sin código de unión.

7. Los nodos son iguales

Un nodo es un núcleo en ejecución. Los nodos se conectan para formar una red. Un path remoto funciona exactamente igual que un path local — el núcleo gestiona la federation de forma transparente.

/local/db/users/query       # procesado localmente
/node-west/db/users/query   # enrutado a node-west, mismo formato

Un module no necesita saber si un recurso es local o remoto.

8. Propiedades de los recursos

Cada recurso declara su modo de acceso: READ, WRITE o RW. Ningún recurso existe sin un modo de acceso declarado. Esto se aplica en el momento del registro.

9. Autenticación de módulos

Cada module se autentica al cargarse. Las credenciales provienen de la configuración (usuario + contraseña o API key). Por defecto = root. Los permisos se heredan por todo el código que ejecuta.

10. Todo es un evento

Cada escritura, ejecución o modificación emite un evento. Los eventos se encadenan: un evento dispara N más. Nada sucede en silencio.

Este es el sistema nervioso de TLS. Una escritura en caché emite un evento. Un webhook escucha. Un cron job se dispara. Un registro de auditoría lo graba. El sistema se observa a sí mismo.

11. Los ficheros de configuración son documentación

Cada fichero .conf enumera TODAS las opciones con comentarios, descripciones y valores por defecto. El fichero de configuración ES la documentación. Un usuario nuevo lee la configuración y comprende el module.

12. Nombres universales de recursos

Todos los recursos usan la misma sintaxis de path en todas partes. ls, get, set funcionan de forma idéntica para local y remoto. Los recursos se encuentran por nombre automáticamente en todos los nodos. Una sintaxis, todos los módulos, todos los paths.

13. Nunca bloquear el event loop

Las operaciones de módulos que realizan E/S deben usar thread pool o epoll. El tamaño del thread pool debe ser configurable. Los nuevos clientes esperan cuando los hilos están ocupados. El event loop es sagrado.

14. Bloqueo exclusivo de recursos

Los recursos físicos (serial, GPIO, IoT) se bloquean automáticamente en la primera escritura. Keepalive implícito por uso. Liberación automática tras 60 segundos de inactividad. La configuración queda protegida mientras está bloqueada. Las suscripciones a eventos permanecen siempre abiertas.

Resumen

#PrincipioEn una frase
1PathTodo tiene una dirección
2MessageUna estructura para toda la comunicación
3CoreEnruta y carga, nada más
4Soft depsLa ausencia se gestiona, nunca es fatal
5Hot-loadLos módulos van y vienen en tiempo de ejecución
6UniversalMisma interfaz para puertos serie y APIs REST
7NodesFederation transparente de núcleos
8PropertiesCada recurso declara READ, WRITE o RW
9AuthCada module tiene identidad
10EventsCada cambio es observable
11ConfigLos ficheros de configuración son documentación
12URNUna sintaxis, todos los módulos, todos los nodos
13Non-blockingEl event loop es sagrado
14LockingEl acceso físico es exclusivo
La solución elegante es la solución correcta. Si un diseño requiere un párrafo para explicarse, está mal. Si una estructura de datos tiene campos «por si acaso», elimínalos. Una estructura de mensaje. Un mecanismo de enrutamiento. Una interfaz de module. El poder proviene de la composición, no de la complejidad.