We have set up a public account to access the Vulcan source tree. The
following

:pserver:fbReaders@...:/usr/local/cvs

The project name is "vulcan" and the password is "fulda conference" (no
quotes, of course).

The code is very much a work in progress, and is released primarily for
discussion. It is known not to build on any platform, and runs only in
my imagination, and then only on good days.

If you would like to roll your makefiles, in component directories there
are file "modules.mak" and "dependencies.mak" with the important stuff.
These are mechanically generated from the MSVC 7 project files *.vcproj
by a master configuration file vulcan.conf. Vulcan.conf is obscure but
available for your amusement.

There are two major new pieces, components "why" and "config". Why is
the new Y-valve. Config is the object based configuration scheme and
associated friends and relations. Unlike the old config file manager,
the one one is context (i.e. database) dependent, with the appropriate
ConfObject handing off the database block (formerly dbb, now Database).
Most, not all, configuration file references now have a trail back to
the database block.

I'm generally happy with the implementation of the new configuration
manager but have reached any firrm decisions the fine structure of
objects and associated attributes. I have tried to maintain fairly
strict backwards compatibility, even when I think the old scheme was
particularly unwise. We should be able to include exiting configuration
files and have the right things happen. Attributes declared within an
object will always take precedence over attributes declare globally.

Please note that no files includes anything that is not required, but do
contain everything that is required, save firebird.h. This policy
covers both header and code files. All new header files declare
referenced classes, but contain only the specific class being defined.
There are no new proto.h files, and there will not be.

The configuration files are example of how I write C++. Simple code, no
templates, no artificial datatypes. Then mean number of lines per
method is probably under ten and the median about four (plus or minus
blanks). I use blank lines to set apart branching code, and indentation
that reflects the language structure of C++. I don't object to
inlining, and there are methods that eventually will be declared inline,
but for rapid development I like to declarations in declaration files
and code in code files. Silly, silly me.

New classes do not use pools, and are responsible for their own cleanup
with destructors and/or addRef/release.

I am using JString where appropriate. I'm willing to substitute an
equivalent string class if a better one becomes available. Do note that
the current JString uses a 32 bit use count and has a less brain dead
concatenate operator.

I am in the process of phasing out all code that uses the std library.

I haven't consistently added modules header boilerplate. All code is
copyright Netfrastructure, Inc. and James A. Starkey. All virgin
modules with be adorned with the IDPL. Modules contaminated with stuff
cobbled from Interbase code with be Interbase Public License.

Comments, anyone? Anyone? Anyone?

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376