Re: A few questions regarding bones

Juergen Schoenwaelder (schoenw@ibr.cs.tu-bs.de)
Wed, 15 Feb 1995 23:09:39 +0100

Hi!

On Wed, 15 Feb 1995 18:44:15 +0100,
Patrick Weemeeuw <Patrick.Weemeeuw@kulnet.KULeuven.ac.be> said:

Patrick> I would like to verify a few statements about bones
Patrick> that I found out by trial and error:

Patrick> - there is only single inheritance

yes.

Patrick> - each (sub)class must define at least one extra
Patrick> attribute (otherwise the configuration cannot be
Patrick> parsed)

We never tried, but it is very likely.

Patrick> - superclasses that inherit from Audit must be hidden,
Patrick> because otherwise the lower level objects have the
Patrick> attributes 'createdBy' etc. from audit multiply
Patrick> defined

No, the idea was that you can not create instances of a hidden class
(like an abstract C++ class). These classes should be used to define
common attributes for a set of subclasses.

Patrick> - What's the precise meaning of the KEYS keyword for
Patrick> classes: must each combination of keys be unique (and
Patrick> can objects be retrieved using a combination of keys),
Patrick> or is it simply a means to have a name for objects
Patrick> that is more descriptive than <Class><sequence nr>?

The keys should be unique. Currently, this is not enforced by the
bones server :-(

Patrick> Besides this, is there a standard method to
Patrick> (semi)automatically extract say IP addresses out of
Patrick> bones to feed it in the tkined configuration files? I
Patrick> don't like the idea to have to update several
Patrick> configuration files manually each time an ip number
Patrick> changes.

Agreed.

Patrick> The approach I'm thinking about is having for each
Patrick> tkined entity two extra attributes (bones class name
Patrick> and key), and providing a method to pull all the info
Patrick> regarding that item out of bones and define it as
Patrick> attributes for the tkined entity.

There is an attribute oid for every tkined object since the early
days. It was intended to be used to hold a key to a database. It is
accessible from the tkined script interface using the `ined oid'
command.

Regarding bones, I must admit that I am not very happy with the
software. It is very likely that I will drop it and use msqltcl
instead. msql is a really fast and simple SQL database server written
by David J. Hughes -- a wonderful piece of work.

Using a fast SQL interface makes it possible to use oracle or sybase
on sites that have commercial databases available. All what need to be
done is to define an easy to use interface that will associate tkined
objects to database entities. This is not as easy as it may look, as I
would like a solution that allows to use tkined and the database
standalone and in combination. It should be possible to discover
networks and to move the result into the database (creating new
objects if they are not known), to download from the database, to move
attribute definitions to/from the database etc. I would also like to
just put a node on the canvas, give it a and run a script that makes a
guess which database entity to use. This requires to handle non unique
names, multi homed hosts, hosts with changing IP addresses etc.

If you have ideas on how to do this right, please let me know. All
suggestions and contributions are very welcome.

Juergen