Re: [Firebird-devel] .e files

[Ann W. H. <aha...@ib...>]

At 11:58 AM 5/17/2001 -0400, Tom Coleman wrote:
>
>  It seems to me (Read: my uneducated opinion is) that a lot of the
>  tools to manage the .e files were left behind with the Open source
>  release.

That's really not the case.  Some of the understanding of the use
of the tools has been lost over time.  Let me give you more background
than you could possibly want.  As many of you know, InterBase is the
second implementation of jrd (Jim's Relational Database).  The third
JJRD (Jim's Java Relational Database) was a non-starter, and he's now
working on number four.  However, when he started number two, he had
a good idea where he was going.  He started by writing the core of
gpre.  As soon as it was running, he rewrote it to use itself.  There
was no database, so it built itself off hand coded C structures that
represent metadata.

 From the beginning, the engine was built with gpre.  The core
functionality, everything but codes.e, can be built from the
C structures.  To build the utilities, a running engine was
nice, but the engine can be brought up without a running engine.
It had to be - we ported the thing to 19 platforms, not all of
which were "standard" - varying endianness, varying alignments,
varying word lengths.

This is how a port worked.  First, the c files for gpre are compiled
on the new platform.  The gpre .c files are quite transportable. The
header files contain macros which define system specific quirks and
those files needed tweaking.  That hand-built gpre was used (with the
-g switch) first to generate itself again, then to generate the c files
for the engine.  Codes.h was just copied over, because a new port did
not require new error codes.  Once the engine was running, it could
connect to another server - whatever was around - and  build the rest
of the stuff.  Or, if necessary, it could create a local database and
go from there.

>  I know that it's very tempting to tear code out when you don't
>  understand what it does, but is it at all possible that we might
>  just be better off without the .e files?

If we're prepared to convert those files from static GDML to
dynamic SQL, we might be better off.  I wouldn't, but I know
GDML.

>  Maybe a short digression from you (an obviously informed source)
>  clarifying the intended purpose and use of the .e files would help
>  me to sort this out.

Jim (and I and everyone else who worked for Jim) considered a database
as normal a part of a programming environment as the file system, and
a good deal more useful.  You're coming from a different place, where
the bounds of CVS play a great role in your choice of tools.  Remember
too, that InterBase is driven of "live" metadata tables, so being able
to read and write to the database as a database is important.

Part of our problem is that we don't have any way to share databases
around the world.  I have a fairly wide pipe and a Linux system that's
not terribly busy and could host some standard databases - messages,
tcs, etc. - if that would work for anyone.

Here's a list of the .e files and what they do.

./alice/met.e           - get metadata, used in gfix.
./burp/backup.e - reads metadata
./burp/restore.e        - writes metadata
./dsql/array.e          - creates/reads arrays
./dsql/blob.e           - creates/reads blobs
./dsql/metd.e           - gets metadata
./dudley/exe.e          - updates metadata
./dudley/extract.e      - extracts metadata
./gpre/met.e            - reads metadata
./isql/extract.e        - extracts metadata
./isql/isql.e           - ???
./isql/show.e           - reads metadata
./jrd/blf.e             - reads RDB$FILTERS to implement blob filters
./jrd/codes.e           - creates codes.h
./jrd/dfw.e             - updates metadata
./jrd/dpm.e             - data page manager, reads RDB$FORMATS
./jrd/dyn.e             - updates metadata
./jrd/dyn_def.e - creates metadata
./jrd/dyn_del.e - deletes metadata
./jrd/dyn_mod.e - updates metadata
./jrd/dyn_util.e        - does other useful things with metadata
./jrd/envelope.e        - apparently abandoned
./jrd/fun.e             - function lookup in RDB$FUNCTIONS
./jrd/grant.e           - updates RDB$RELATIONS, RDB$SECURITY_CLASSES
./jrd/ini.e             - initializes things - shouldn't probably update 
metadata
./jrd/met.e             - metadata manager
./jrd/pcmet.e           - metadata manager for 16 bit Windows
./jrd/scl.e             - reads/updates RDB$SECURITY_CLASSES
./jrd/stats.e           - utility routine to gather performance statistics
./qli/help.e            - reads help database
./qli/meta.e            - reads/updates metadata
./qli/proc.e            - reads/updates QLI$PROCEDURES
./qli/show.e            - reads metadata



Regards,

Ann
www.ibphoenix.com
We have answers.