Existe división de opiniones en cuanto a cómo deben ser los espacios de nombres y los nombres en un SO.
Por un lado, hay sistemas [120, 2] que utilizan un único espacio de nombres para todos los distintos tipos de abstracciones (ej. Amoeba utiliza capabilities que se emplean para denotar unívocamente cualquier tipo de recurso) y por otro lado, tenemos sistemas [59, 138] que utilizan distintos espacios de nombres para distintas abstracciones. En sistemas de espacio de nombres único un nombre siempre representa al mismo objeto. En sistemas con múltiples espacios de nombres un nombre puede denotar objetos distintos en espacios de nombres distintos.
El primer enfoque (espacio de nombres único) conduce a sistemas de nombrado más simples de utilizar, complejos de implementar y de más alto nivel de abstracción. El segundo conduce a sistemas de nombrado más complejos de utilizar, simples de implementar y de menor nivel de abstracción.
El enfoque adoptado en un DAMN es el de múltiples espacios de nombres (uno por cada abstracción o recurso suministrado por el sistema) en correspondencia con la multiplicidad de espacios de nombres existente en el hardware (en una arquitectura dada el hardware hace que un entero pueda identificar a un marco de página, a una línea de interrupción, a un trap, etc. dependiendo del espacio de nombres empleado). La adopción de múltiples espacios de nombres facilita la extensión al conjunto de la red de los nombres físicos (los utilizados por el hardware) del modo más adecuado en cada caso. Seguimos pues las directrices 6 y 3 mencionadas en el apartado 2.1.1, según las cuales debe preservarse la diversidad y los nombres deben ser válidos en la red y corresponder con los empleados por el hardware.
Considerando ahora la estructura de los nombres en sí, algunos autores
sostienen la conveniencia de utilizar nombres homogéneos
, únicos, opacos, de alto nivel que mantengan
la transparencia de ubicación [120, 2].
También encontramos otros autores que sostienen la utilidad y
conveniencia de utilizar nombres heterogéneos y de bajo nivel como los
suministrados por el hardware [59].
Los primeros son los más convenientes para la distribución del sistema dado que pueden utilizarse desde cualquier punto de la red con independencia de su posición. No obstante, también degradan la adaptabilidad y el rendimiento del sistema puesto que la información que contienen es inaccesible a las aplicaciones y habitualmente requieren de niveles intermedios de traducción hacia los correspondientes nombres físicos.
Los segundos son buenos en cuanto a adaptabilidad y rendimiento se refiere, pero no son adecuados para un sistema distribuido.
En un DAMN los nombres deberían aproximarse tanto como sea posible a los nombres físicos empleados por el hardware. Esto conduce al empleo de nombres heterogéneos y de relativamente bajo nivel de abstracción.
En Off tenemos tres tipos de recursos que hemos de nombrar:
Estos elementos pueden subdividirse en unidades elementales, constituyendo éstas las mínimas unidades asignables.
Dado que en cada uno de los puntos anteriores las necesidades son diferentes Off trata de adoptar en cada caso los nombres más adecuados sin intentar imponer el mismo modelo de nombrado a todos los recursos existentes. De hecho, el énfasis en el uso de un mismo modelo de nombrado para todos los recursos es algo que tiene que ver con el suministro de abstracciones y no con la conveniencia y eficacia del sistema de nombrado.
De haber impuesto el mismo tipo de nombres a todos los recursos habríamos pagado el precio (en eficiencia y rendimiento) que pagan otros sistemas que lo hacen y habría sido necesaria la introducción de niveles intermedios de traducción de nombres.