On 11/8/05, Christopher Nelson <[EMAIL PROTECTED]> wrote: > > > Assuming that the server's service requires the filename > > (perhaps it > > > is a filesystem server, or perhaps it is a photo album > > server... Both > > > services are equivalent in this example.) then of course it has to > > > process the filename. At some point someone has to > > actually process > > > the filename. Otherwise there's no point in having it. > > > > The name is for you to know what is in the file. The server > > does not need the name to know that. > > Eventually, some server needs to know the filename. How else is the > file mapped to its content? If you are using a hierarchical filesytem, > *someone* has to walk the filename to get to the data. If you are using > an object-based, single-level store, you *still* have to identify some > objects with human friendly names. That is symbolically analagous to a > filename. So while not *everyone* needs to know it, and some point some > server has to know it.
You can just read the symbolical name and present it to the user, or search for an object with the name requested by the user. Still it can be your application (or some code in libc) that resolves the human friendly names, and the server and software that does not want to deal with the complexity can avoid it. Certainly some code for finding the requested name must exist. But it can be place in several places. For one, in the current Hurd the translator only knows how to resolve names in its own namespace. If another translators are attached at some points in the path, the lookup is iterated over these translators in libc. If libc can work with this, it can work with inodes numbers, or whatever else is short enough. Thanks Michal
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
