[brainix commit] r193 - wiki
codesite...@google.com
Date: Fri Aug 24 06:51:21 2007
New Revision: 193
Modified:
wiki/HighLevelVFS.wiki
Log:
Edited wiki page through web user interface.
Modified: wiki/HighLevelVFS.wiki
==============================================================================
--- wiki/HighLevelVFS.wiki (original)
+++ wiki/HighLevelVFS.wiki Fri Aug 24 06:51:21 2007
@@ -102,4 +102,10 @@
I just noticed that the changes I'm proposing are the same as those when converting from an [http://en.wikipedia.org/wiki/Representational_State_Transfer#Example RPC representation to a RESTful representation] of the files and functionality abstracted by the kernel. Notice how instead of defining many different syscalls as in RPC, the REST/CRUD model follows a simple set of 4 I/O operations and access to different files/functionality is moved to a hierarchy of names. In other words, this high-level VFS proposal is more "web-like". (jdt)
-- I'm preparing to leave town for the D Programming Conference in Seattle, Washington, but here are a few preliminary thoughts: it seems that this is a simple map where a "location" is a synonym (an alias if you will) for a file. This, RPC paradigm translated into file crap, becomes a simple dictionary then. But I see we are focusing on the REST approach, so 86 that dictionary then. Perhaps instead of using "http://" we could use "file://", but this approach would change the file hierarchy no? So instead of having "/dev/null" we would have "file://root/dev/null" (or more appropriately "file:///dev/null")? I think the resource approach is more object oriented, more unix-like iff we make a resource an alias for a file. Or we represent it as-a file, vnode, what have you. This idea I will think about for a bit. I'll be back Saturday the 25th, but I'll try: thinking about this some more, revising my research to be more comprehensive, and having fun at the conference :) (pqnelson)
\ No newline at end of file
+- I'm preparing to leave town for the D Programming Conference in Seattle, Washington, but here are a few preliminary thoughts: it seems that this is a simple map where a "location" is a synonym (an alias if you will) for a file. This, RPC paradigm translated into file crap, becomes a simple dictionary then. But I see we are focusing on the REST approach, so 86 that dictionary then. Perhaps instead of using "http://" we could use "file://", but this approach would change the file hierarchy no? So instead of having "/dev/null" we would have "file://root/dev/null" (or more appropriately "file:///dev/null")? I think the resource approach is more object oriented, more unix-like iff we make a resource an alias for a file. Or we represent it as-a file, vnode, what have you. This idea I will think about for a bit. I'll be back Saturday the 25th, but I'll try: thinking about this some more, revising my research to be more comprehensive, and having fun at the conference :) (pqnelson)
+
+= Image of Proposed Layout =
+(this is preliminary)
+http://brainix.googlecode.com/files/high_level_vfs.svg
+
+