On 6/19/2011 9:49 PM, Julian Leviston wrote:
On 20/06/2011, at 2:33 PM, BGB wrote:
in a sense, the metaphor no longer works, and should likely itself be left to
fall into the recycle-bin of history. worse yet is having to read stuff written
by people who actually take this metaphor seriously.
Given the historical perspective, it was appropriate at the time. These days, our
computers are so vastly scaled beyond the original intention of the "file"
metaphor that it's getting silly, I'd grant you that.
yep.
It's not really any surprise, then, that Apple's trying to "get rid" of the file system,
is it? :) Mind you, I think the "app" metaphor is just as crappy, personally. I like the
idea of workflows much more, and combining a few small simple tools together to get some particular
job done.
interestingly, I don't believe in getting rid of the file-system,
per-se, as technically it works fairly well and is a proven piece of
technology.
but, mostly, I just want the filing-cabinet metaphor to go away, if
anything, so that people making stupid computer/filing-cabinet analogies
will go away, or worse yet, talking about computers implying that they
themselves are subject to the same sort of limitations as filing
cabinets, or describing technical limitations WRT computers and data
storage which haven't really been the case since maybe the 70s or 80s...
(such as claiming that files are simply collections of fixed-format
records and are unable to store heterogeneous data, leaving me to think
"WTF?...").
if I could make any notable change to how filesystems worked, it would
be likely to introduce user-defined VFS systems as an OS-level facility.
this would mean one of several things:
ability to more easily introduce user-defined virtual directories as a
part of the host operating file-system (as is, on both Windows and
Linux, it is a little nasty...);
ability to run apps (and parts of apps) inside of custom VFS's (more
like finer-grained chroot);
potentially a "virtual mount" facility, where an app can locally
mount/unmount volumes it has rights to, and can choose whether or not
they are visible to the external OS (say, an app might mount its own
data-files as volumes, and choose that only itself can see them);
...
as-is, it is generally less nasty to do this within the app, essentially
having the app provide its own VFS and drivers (for example, my project
can mount zip-files as volumes, including for random read/write, albeit
with a few limitations...).
going more extreme, one could begin to blur the line between files and
in-program objects and code (say, packages, functions/methods/variables,
... could be potentially visible as part of the VFS).
implementation-wise, there is likely to be a layer of separation above
the true filesystem (this would introduce a huge number of tiny files
which would not map effectively onto most existing filesystems, and so
it would seem better to introduce this as a "virtual mount").
another possible idea could be to go from a traditional
"mount/unmount/fstab" style system, to possibly supporting a mechanism
partway between mounts and symlinks (one doesn't "mount" a volume, they
"link to it"...). I am partly imagining "links" partway between
Unix-style symlinks, and the links supported by Windows, but with more
features (such as ability to mount something via accessing a link, or
redirect to a network resource such as a CIFS/HTTP/WebDav/FTP share).
and, for something like the prior concept, they can create a link from a
directory into a program, allowing the program to fill a role partway
between being an application, an FS driver, and an OS service.
taken further, this could also potentially be partly used as an
alternative to traditional DLL/shared-library and IPC/RPC mechanics as
well (could get hairy, primarily if C/C++ and data sharing are involved,
potentially limiting to high-level "managed" types, which may either be
copied or passed as handles...).
worst case for the above, probably can't be too much worse than MS's COM
system (COM / COM+ / DCOM).
a proper HLL could probably mostly hide the underlying mechanisms.
trivia:
in a much-older version of my projects, it was possible to open network
sockets purely via a VFS "vffopen()" operation, but this feature later
died with a rewrite of my VFS mechanism some years back (I may
eventually re-add it, possibly among several other VFS features, namely
cached HTTP mounts and ability to support virtual file encryption).
basically, the rewrite partly broke my ability to route network sockets
over the local VFS (in general), as well as several other things.
my code also generally works within a local VFS, rather than directly
using the OS provided FS facilities. the VFS is actually one of the
oldest parts of my codebase (dating to sometime around the late 90s...).
For example, when web programming on a specific web app, I use a web browser, a text editor, a database
management program, a command line, and a couple other tools. It'd be nice to be able to "fit these
tools together" into a pseudo-app and then build "documents" for this pseudo-app... that were
accessible within the pseudo-app (ie not the file system) to use Apple's idea, and that could simply do all
the things I generally need to do... (there are only a few "tasks" I generally do and none of them
correlate directly into any one particular application).
I love the way I edit text in my one particular text editor. Why do I have to
use a different editor to edit my email text? lol... it makes little sense.
well, mostly I am using Windows Explorer and the shell (both CMD and
Bash) for managing things on Windows, and this setup works "adequately".
admittedly, I am not entirely sure how the idea you are describing will
work, so maybe it can be described in more detail? (like, what parts it
may contain and how they may fit together...).
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
