Re: Database storage approach
- From: Duncan Pierce <cmrdrp soc staffs ac uk>
- To: Alexander Peuchert <peuc peuchert de>
- cc: gnome-list gnome org
- Subject: Re: Database storage approach
- Date: Tue, 27 Apr 1999 13:47:55 +0100 (GMT)
Hi Alexander,
On Tue, 27 Apr 1999, Alexander Peuchert wrote:
[snip]
> How about using a database for file storage instead the file system.
I posted a rather wordy proposal for a similar idea some time ago on the
gnome-devel-list. It didn't attract much attention, unfortunately.
[Miguel was opposed to the overhead of accessing everything through CORBA]
Basically I was interested in generalizing the idea of a file system to be
treated like an object database (accessible through CORBA) with an
essentially hierarchical structure (i.e. objects can "contain" other
objects). The user's local filesystem can then be exported in an
objectified form, BUT where a file can be interpreted sensibly (e.g. we
know its MIME type and have a server for it) we can perform the activation
of a CORBA server on the underlying file, and access that using a client
speaking CORBA. In effect, the filesystem has been swapped for an object
database with the same structure and has, in the process, been generalized
to handle more than just files, directories and symlinks. Nested
databases could be held within it, for example, and indeed you are not
even tied to having a real filesystem-based implementation - it could all
be in a database. Only the CORBAfied API matters.
The idea generalizes beyond local filesystems to objects accessible
through FTP and HTTP (HTTP should work especially well since the protocol
specifies the MIME type of data being transferred) and in nested
databases. Usefully, clients do not have to know about HTTP/FTP or even
objects held in tar.gz or structured storage files. With a little work,
neither do the servers.
> There would also be a possibility to let the user chose from the file
> dialog between the database access and the file system.
With what I propose, it is possible to have everything in one unified
structure, so there is no need to choose explicitly via dialogs - it is
simply part of the process, like specifying a directory. I had not
previously thought about including indexing data for fast searching, but
why not? Associative lookup for data would be very powerful.
There are many advantages, including remote and shared access to
persistent objects, and a nice way to access DOM-based document objects
which ties in with the gnome-dom module.
I have done some preliminary work with CORBA on this, and discovered that
writing persistent objects with CORBA is more difficult than I expected!
Because there was no interest, I shelved the idea, but if people are
interested then I will carry on with it. But maybe we should think
carefully about what we want first? It would be too easy to attempt
everything and end up achieving nothing.
-- Duncan Pierce (D.R.Pierce@soc.staffs.ac.uk)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]