5 ms·

I don't think it's the paradox of choice at work. I think instead that the set of file operations happens to permit arbitrary interaction with an object. Spec

by jude- 12y ago

I don't think it's the paradox of choice at work. I think instead that the set of file operations happens to permit arbitrary interaction with an object. Specifically, file operations already represent: * data accesses (read), * data mutations (write, trunc), * metadata accesses (readdir, closedir, stat, statfs, readlink), * metadata mutations (creat, mkdir, link (and symlink), unlink, rmdir), * interaction contexts (open, close, opendir, closedir), * namespaces (mount, umount). I would argue that any object (OS-level or otherwise) can be represented as a filesystem. The advantage of doing so is that the client interface stays the same in all cases. I think it's this constraint on the interface that makes file operations and filesystems so appealing in the long run.

pjmlp 12y ago
Now try to do real time 3D graphics with those operations. Plan9 window manager is not an example of performance.
- jude- 12y ago
  Depending on how it's implemented, there's no real reason why it couldn't be done. For example, I could create SceneGraph_fs, which exposed the scene graph of objects as a directory hierarchy. The filesystem's toplevel directory would be organized with a /scenegraph/ directory for the scenegraph, /lights/ for the light models, and /tmp/ for a scratch space for constructing objects and staging them to be added. Each node in the scene graph would be represented by a directory under /scenegraph/ which contained one file for each distinct chunk of data the graphics engine would need to know (like a position matrix, an orientation matrix, a mesh model, a texture map, etc., depending on whether or not the directory represented a model or a transformation). For data in /scenegraph/, SceneGraph_fs would accept well-formatted writes to a node's files as a means to update the node in the scene--for example, to translate the node, you would write a new matrix to the object's positional matrix file (the write() would return EPERM if the matrix was malformatted). To create or modify an object atomically, you could describe it under /tmp/ in SceneGraph_fs, and rename() it into place. You could manage lights and lighting data in the same way. Of course, the graphics card interfacing happens in filesystem implementation. But, the application interacts with the scenegraph as a filesystem, not as an object.
taeric 12y ago
Right. My point is that you have to make your operations fit within that language. As opposed to the object metaphor, where you get to define the language however you want. Very similar to the REST versus SOAP/whatever paradigm. Neither one should be more capable than the other. In fact, REST should be the more restrictive choice. Right?

by jude- 12y ago

pjmlp 12y ago

Now try to do real time 3D graphics with those operations. Plan9 window manager is not an example of performance.

jude- 12y ago
Depending on how it's implemented, there's no real reason why it couldn't be done. For example, I could create SceneGraph_fs, which exposed the scene graph of objects as a directory hierarchy. The filesystem's toplevel directory would be organized with a /scenegraph/ directory for the scenegraph, /lights/ for the light models, and /tmp/ for a scratch space for constructing objects and staging them to be added. Each node in the scene graph would be represented by a directory under /scenegraph/ which contained one file for each distinct chunk of data the graphics engine would need to know (like a position matrix, an orientation matrix, a mesh model, a texture map, etc., depending on whether or not the directory represented a model or a transformation). For data in /scenegraph/, SceneGraph_fs would accept well-formatted writes to a node's files as a means to update the node in the scene--for example, to translate the node, you would write a new matrix to the object's positional matrix file (the write() would return EPERM if the matrix was malformatted). To create or modify an object atomically, you could describe it under /tmp/ in SceneGraph_fs, and rename() it into place. You could manage lights and lighting data in the same way. Of course, the graphics card interfacing happens in filesystem implementation. But, the application interacts with the scenegraph as a filesystem, not as an object.

taeric 12y ago

Right. My point is that you have to make your operations fit within that language. As opposed to the object metaphor, where you get to define the language however you want. Very similar to the REST versus SOAP/whatever paradigm. Neither one should be more capable than the other. In fact, REST should be the more restrictive choice. Right?