lkml.org 
[lkml]   [1996]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectQ: Arbitrary database interaction specification file system?
I want an arbitrary mechanism for specifying the interaction to a
database, for purpose of use by a special filesystem (say adisfs)
which will interface that fs to Linux (or for that matter other OSs).

(The Q is where to discuss this. I think it's a *bit* off-topic for
both lists but not entirely.)

In this way, my application can create an efficient database, upon
which legacy tools such as MH & INN could interact, effectively
gearing the fs for the application. The database could be something I
create or I could use available databases (from companies, even;
oracle, etc. etc. etc.). Oh, btw, my application is a working
environment that's easy to implement because it already exists, and so
does the database, so I don't want to have to convert much; this would
achieve that (can you say afio?)

This fs would not have to be reimplemented, and it would allow a great
deal of the operations of any database which wanted applications based
on it which use the Unix abstraction of file as object to be made
efficiently and easily. Ok yeah that was a garbled sentence.

Else, applications will bloat and I'll be searching endlessly for an
operating system based upon the (arbitrary, not-disk-bound) object as
metaphore without any attempts at not making access to and storage of
said objects difficult.

Or, is this just an instance of Unix+MH being more reliable than pine,
and I'm scared ****less of having to invoke my 500MB mail database in
a single pine process as a part of my opening the newest mail arrival
while trying to work efficiently to make real cash?

What types of FSs come close to this that I could test-try?

How hard would it be to stick something like this into Linux?

Is this unrealistic garbage?

As I sit here watching my MH/INN legacy databases bog down with
sequential searches and my disk space disappear due to lack of
compression ...

Bradley Allen
<Ulmo@Q.Net>


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.028 / U:6.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site