The first messages described the purpose of this feature -
to allow two systems that share alignment rules and datatypes
to access the same database, even if the systems have different
endian rules. This allows a software producer to distribute a
single database on a CD that can be read on Intel and PowerPC
platforms, for example. This capability is required if anyone
wants to provide a generic Firebird for Mac OS.

The second message described the transformations required on
structural data.

This message describes how user and system data are transformed.

Records on disk are stored with the format number that was current
when they were stored. The format is a descriptor of the record,
field by field, type and length. Data is inverted from VIO, after
it has been expanded when it is read, and before it is compressed
on write. The inversion routine takes the record pointer and the
format block and uses the format block to iterate through fields,
inverting as necessary.

There are a couple of subtle points.

When the transaction needs to reference a back version and the
back version is a delta, the primary record version is inverted to
local format when it is read, then converted back to its native
format to have the differences applied. The result is then inverted
again to local format. This gets slightly more complicated when
garbage collecting because the record must be in local format when
it goes on the going and staying lists for blob and index garbage
collection.

Blob ID's have two states - permanent and temporary. They're
handled differently because the temporary blob id is 32 bits
of null value and 32 bits to locate the temporary blob. The
permanent blob id has a 16 bit relation id, eight unused bits,
and a 40 bit record number which is one byte plus one native
format 32 bit integer.

Generally blob data is left to the application designer as the
database has no clue about the content of blobs. The exception
in user data is that segment lengths in segmented blobs must be
inverted.

However, blob data in system tables is Firebird's responsibility.
Calls from met.epp and dfw.epp handle the conversion of format
descriptors and the RDB$RUNTIME blob.


Unlike the other utilities, gstat does its own I/O on the database
file. It will need to call the routines that invert structural
data to work on other-endian databases. Since that's a single call
to the inversion code on read and gstat doesn't ever write anything,
that should be easy. The other utilities are just wrappers around
system calls.



Essentially these message describe the full implementation of a
mechanism to allow access to other-endian databases. It seems like
a useful feature to me.


Regards,


Ann