On Thu, 16 Feb 1995 09:37:52 +0100,
Patrick Weemeeuw <Patrick.Weemeeuw@kulnet.KULeuven.ac.be> said:
Juergen> Regarding bones, I must admit that I am not very happy with the
Juergen> software. It is very likely that I will drop it and use msqltcl
Juergen> instead.
Patrick> Could you please elaborate a bit about this? Is bones
Patrick> not reliable enough, or does it lack any important
Patrick> functionality? Or perhaps it simply seems like a
Patrick> waste of time to implement and support yet another
Patrick> database, when other people do already a fine job
Patrick> regarding this...
In short, all of above. (Before I go into details, please note that I
am not a database guy.)
We started to look into databases when we started the project. Our
requirements were something like
o reliable database backend
o easy and fast network access
o usable for network management applications
o easy to install and use
o portable and freely available
We first tried the postgres system. It really had nice features (you
could map extended entity relationship models directly on the postgres
data model, define you own data types, record historic data etc.). But
it turned out to fail regarding portability, speed and reliability (I
am talking about the version of 1992 - it may have changed). Postgres
also includes a transaction manager, which is good in most situations.
But network management software requires very fast database systems if
you want to get acceptable response times and transaction management
is too much overhead to be acceptable.
Our second approach was to write our own lightweight database server.
We picked GNU gdbm files (which were considered fast because they use
an extensible hash mechanism) and I wrote a RPC wrapper around the
gdbm API that allows to access gdbm files using a RPC server. This
worked quite well. (Sun RPC turned out to be not very portable because
there are old and ugly versions which are still delivered by some
vendors. And it is a mess to implement authentication mechanisms if
you use rpcgen as you do not have access to connection parameter. This
requires to run machine generated files through sed to fix them up.)
While the backend was usable, the C++ frontend called bones turned out
to be big and slow and not very flexible. As some students here had
decided to use this system in their projects, we started to replace
the C++ frontend with a lightweight Tcl interface. This is the version
which is on our ftp server.
You may ask, why I am thinking about switching to msql now that we
have something useable? There are a couple of reasons:
o Further development of tkined and scotty is my primary goal.
If I can get a database backend which is good and maintained
by an active community, I can save much time that I can spend
on tkined and scotty.
o The SQL interface of the msql server allows to do basic
operations on the server. The bones system does only provide
network transparent access to bones objects. Retrieving
an object by some arbitrary criteria requires to download
all objects and sort them out locally.
o SQL is well known. It does not require to learn a new
`language' as most students know about SQL basics today.
o The msql server is really fast. It uses mmap() to read database
files and it does not need to care about transactions as there
is only one query processed at a time. You have to know that
David developed msql for his network management project called
Minerva so it is suited for network management tasks.
o There is a Tcl interface to the msql server which is very close
to the Tcl interface for oracle and sybase. This allows to switch
to commercial systems where/if needed.
Patrick> Actually, I was just about to use bones to implement a
Patrick> database with all kinds of configuration information,
Patrick> users, etc... exactly the stuff that bones seems to
Patrick> be designed for.
Bones was written because there was nothing usable out there when I
started to work on it. Msql is a good backend and it took me about an
hour to convert the bones.conf file to a msqltcl script that creates
tables to hold the same information. It would be possible to emulate
the old bones interface on top of msql, but I prefer to rewrite our
code based on msqltcl. If it keeps raining during the weekend, I will
probably find some spare time to fix up what I already have done so I
could make it available if there is interest.
I would really appreciate comments on the database layout etc. But
note that I have only very limited time to spend on it. BTW, I have
heard that the developer of the msqltcl interface is working on a
generic Tk-based msql database browser. I have not seen anything yet,
but this could be a very nice frontend for maintaining the
configuration database.
Juergen