The OP stated 'jar' and I presumed '..on file system
or web server'. But good point, for all I know, the jar
may be stored as a (whadda'ya'callit?) BLOB in the
DB.
Some databases can in effect be accessed via a URL. Those backing Web
servers come to mind.
In fact, on a Windows system a custom URL handler that accesses a
database can be written and installed. I'm not sure about Unix systems
(including MacOS X) but they probably have some sort of system-wide
URL handler capability too, at least if they have decent modern window
managers (as MacOS X presumably does).
Another thing to note is that the next generation of filesystems is
likely to be built on full-blown ACID database logic, for robustness,
scalability and other benefits, now that typical home computing
hardware can easily accommodate such a thing. (They may also be
associative, discarding the concept of a unique "parent directory" and
any distinctions between hard symlinks and "the real location" of a
file or directory. Files are deleted when they no longer have any
parents at all, aside from the root never being deleted (it may have
itself as a parent instead of no parent to avoid special-casing it).
Semantic link types might exist as well, allowing other sorts of links
than "this file or directory is a child of that directory". It could
be as big a change as the change from flat to hierarchical in the late
1980s, when there were still personal computers in widespread use with
8-bit microprocessors with no MULTIPLY instructions and a flat
directory of six-character-maximum file names on each disk, clearly
not at all suitable to scaling up much above a few dozen files ... not
that those 5 and a quarter inch floppies could hold very many ...)
Regardless, I can tell you right now that even the venerable NTFS is
showing age and creaking under modern loads of millions of files,
hundreds of gigs, and really long paths and file names to keep all
those millions straight. A DB based system would tolerate duplicate
file names, since a GUID key would be used under the hood to identify
each file, and ordinarily would not be needed by or exposed to the
user. This is what allows the "unique parent" and distinction of links
from "the real file" to go away, and it even permits anonymous files.
Temp files need never risk collision again. Users making temporary
files or copies or otherwise fiddling around needn't bother coming up
with unique names for things that may not even last as long as coming
up with a name and typing it would take. When a file becomes important
that didn't used to be it can be given a proper name, or renamed from
a poorer name to a more descriptive one, and its GUID won't change so
it will still be found by anything that references it, providing the
referencing uses the GUID under the hood. Applications can appear as
containers with their code and data files inside (kind of like JAR
files now?)...if a file named "foo.cfg" is inside the application, it
uses this file as a config file ... finding the application's stuff is
easy as it's inside the application itself, in a sense. User-specific
data is in the intersection of that user's home "directory" and the
application container; the application loads the first "foo.cfg" it
sees that is in this instance's user's home directory and in its own
container; or loads all of them, with the possibility that an
arbitrary one determines particular settings that are set different
ways in different copies. Users who want specifically predictable
behavior should of course make sure only one such file exists in their
own home "directory". File permissions are also made hugely simpler
with a database backing the filesystem that can encode elaborate
permissions. An associative logical filesystem makes permissions
easily based simply on a file being in a (descendant of a) particular
container or not. One for each user, with sub-containers for write or
execute; a world one; one for files the web server makes public; etc.;
user containers put in further containers can create overlapping user
groups which might have associated permissions managed in a similar
way. Applications can get their permissions controlled likewise.
Perhaps putting the application container inside a user container
makes it setuid that user; perhaps a link can be put that makes it so
only when launched via that link. The link itself can be made world
readable or whatever by also including it in other containers. Other
containers might sandbox an application placed inside, restricting it
to sub-normal user privileges. This might be useful for new, untested,
or suspicious stuff, or anything pending a virus-scan in case someone
launches it before someone else gets around to testing it. They might
be emulated, at a steep cost in performance, and only able to "infect"
the temporary VM in the emulator, so the infection goes away when the
emulator is terminated. Only files and containers instanced under the
sandbox appear in the VM emulation, and become potentially vulnerable
to malicious code deleting or modifying them. Indeed, malicious code
may only be able to delete the reference in the sandbox, leaving the
file intact if it is still referenced elsewhere as well, and modifying
a file with multiple references may by default have "copy-on-write"
semantics. Wipe the sandbox and any infection goes away, and there can
be no data loss.
In light of capabilities like these, and consistency/transactional
integrity/scalability advantages, filesystems like this seem
inevitable; it's only a matter of time and research.
Then loading classes from a database will be routine, and loading
classes NOT from a database will be unusual!
