To show what I mean, see the most fundamental Unix utility, ls. The ls program is supposed to give you a list of files in a certain directory. However, it does not give you files, per se. It gives you a list of character strings which match the names of the files.
Without knowing that these strings mean file names, without knowing the directory where ls was searching, these strings are not very useful to other programs. If ls returned a list of file pointers and it was the terminal or other software that translated these into character strings, then a much more robust software environment could be realized.
With this happening in the background, it would be much easier to program a terminal so you could select a filename and get information on the file or launch it, a feature that I've wanted for a long time. Other things would be easier too, since you won't have to write any code to translate strings back into the objects they represent.
- Every object would have a .toString() method so that the terminal could easily translate anything into a string
- Everything would be passed around as nodesets for a unified access method
- Every individual object would be a CORBA-ready XML infoset and whatever else is expected of an object in a modern system.
It seems like a whole new language might be necessary to create my dream OS, or at least, a whole new ABI and compiler. The object structure must also be standardized. We'd need a bureaucracy to declare that each file object must have .name, .bytes, .canRead, etc attributes, for instance.
Another thought: many files currently on Unix systems can be redesigned as compiled nodeset databases, using a standard format for which there would be common viewing/editing tools. Logfiles, especially, would be perfect for this since they are already databases, just in plaintext. The filesystem might need to handle nodeset files differently than it does character-stream files. With everything using the same object structure, generic querying tools would be immensely powerful.