Re: Database storage approach

[Duncan Pierce <cmrdrp soc staffs ac uk>]

Hi James,

On Tue, 27 Apr 1999, James Henstridge wrote:

> The file system is a database of sorts, with efficient methods of
> accessing and modifying the data.  It also has many tools that can be used
> to back it up, and corruption in one part of the file system will not
> necessarily destroy all the data.

Agreed.  There are lots of traditional advantages to using a filesystem,
especially with regard to flexibility.  Speed of access is also usually
quite favourable, although a specialised database can do better sometimes.

But GNOME is about developing a powerful, consistent and user-friendly
environment, isn't it?  No-one is calling the Midnight Commander authors
crazy because they've reinvented "mv", "cp", "ftp" and others besides.
This is because what they have come up with is more accessible for many
users, and even for power users in some tasks.

> Most of the examples you give can be done with current tools (well with
> command line tools, but if it can be done on the command line, it would be
> possible to write a GUI).

(The Gnome search tool is sort-of a GUI for this, maybe not that easy to
understand, though)

> Where are all the gnumeric files?
>   find . -name '*.gnumeric'
> Where are all the files I modified last week
>   find . -mtime 7
> All text files -- you could use find in conjunction with file

Ok, that's a power user's way.  I use stuff like this quite often and
certainly wouldn't want this kind of power to go away.  But it isn't very
mom-compliant, is it?  (For example, I keep having to explain to my dad
how to change directory).

[chop]
> 
> When people start to go on about putting all your documents into a
> database, I think isn't that what the file system is for?  If the file
> system doesn't support a required feature, then maybe it should (eg.
> metadata).  When it is not practical to implement that feature in the
> filesystem (eg. can't add metadata support to filesystems under solaris or
> other commercial unixes), a small change that causes the least upsets for
> other programs is often the best.

I agree with this, too.  But I think that, for a project like Gnome,
although we should actively seek to avoid gratuitous incompatibility with
more traditional unixy ways of doing things, we should also not be afraid
to explore other more accessible (and more consistent) options.

> For your example, if all my documents are stored in a database, how do I
> edit them with plain old vi or emacs?  Can I use sed to perform
> substitutions in the document easily?  What do I do if some other process
> has the database locked for writing? (for this problem, you could have a
> database server that handled all requests and handles locking and
> everything.  But isn't that what the OS does with the file system
> already?)

[No sarcasm intended here, this is a reduction ad absurdem argument:]

If we start storing documents on computer, how do we photocopy them?  How
can you send a copy of a document to someone on the other side of the
world when it's just a bunch of ones and zeros?  How will they be able to
read it anyway?

The point is that, although something is lost, there may well be a gain
that makes it worthwhile.  Although I love emacs dearly and use it every
day, there are a lot of people out there who are not interested in crappy
text files where you can't even do any formatting or include a picture of
your neice when you're writing a letter to your friends in Australia.

> I am sorry if the comments seem a bit harsh, but in this case, I believe
> that the gains from putting all your documents into a database are quite
> small when compared to what you loose.

Well, I'm not specifically arguing _for_ a database, although I think
Alexander is (correct me if I'm wrong, please).  But I disagree with your
comments, in general and especially in the context of the Gnome project.
With a bit of thought, imagination and the hard work to implement it, it
seems to me that something powerful yet simple to use could be built.  It
is new kinds of functionality that are interesting; ones that make sense
in the context of a GUI, rather than thinly covering what happens on the
command line and inheriting all the limitations of that medium.

-- Duncan Pierce  (D.R.Pierce@soc.staffs.ac.uk)