Hi, Jim!

> >2. On ELF systems multiple FB/IB client libraries cannot coexist

inside

> >one process. Period. Failure to obey this rule currently leads (and
> >always lead) to random data corruption and strange behavior.
> >
> >
> Is this true of dynamically loaded libraries? I thought that a .so
> would resolve internal entrypoints a link time, so loading a number of
> libraries with overlapping internal resolved symbols is safe.

It isn't. ELF entrypoint names are process-global. And resolution for
conflicting names strongly depends on library load order, dl_open flags
and run-time access pattern (there is LD_LIBRARY_PRELOAD and other env.
vars on Linux where you can set library load order to get around some of
the issues). This is why Firebird-internal classes and functions should
be put to Firebird namespace to avoid collisions with other programs and
libraries (part of this work is done in FB2 HEAD codebase).

> As an aside, let me grumble that the Unix community has never

understood

> layered software. The the current Firebink link, everything is

global.

> "Grown up" operating systems use dynamic library systems where

external

> entrypoints are marked. Similarly, Unix systems have never learned

that

> name space management is critically import. All programmers pick the
> same names for similar things, but those things vary in detail.

"Grown

> up" languages like Java, C++, and Ada have all developed language
> specific mechanisms to handle the problem that civilized libraries and
> name space management could have solved (OK, often the language

specific

> mechanisms are superior, but the point remains).
>
> >As the result consistent usage of 'isc_' prefix for public constants

and

> >entrypoints is perfectly legitimate and should be followed.
> >
> >Such stuff should not change each time the marketing name of the

product

> >changes.
> >
> >
> >
> It is not legitimate for two organizations without a common conflict
> resolution process to share the same namespace. There is no possible
> compatibility if a program compiles and links but does something
> completely different. Or it becomes impossible to write a system that
> straddles the two systems. If Borland and Firebird could agree to
> resolve the management of name space and numeric codes, then I would
> agree with you and Jason. But this isn't an agreement now and it

isn't

> likely that one will be reached before Firebird 2 ships.
>
> Isc stands for Interbase Software Corporation. Borland bought it,
> Borland owner it. It doesn't belong to Firebird. Borland/Interbase
> legitimately owns the prefix "isc". Yes, they released Interbase from
> bondage, but they still own the prefix and continue to maintain and
> extend the product. While there is probably no legal obstacle to
> masquerading Firebird features as "Interbase Software Corporation", it
> is intellectually indefensible to label services they don't support

with

> their name and to clog up their namespace with our own conflicting
> symbols.
>
> Qualified names exist to avoid name conflict. Using qualified name to
> promote name conflicts is unfair and technically wrong.
>
> Nobody was happy when Mozilla appropriated the name Firebird for their
> product. Borland Interbase has the same right to complain about
> Firebird usurping their name space.
>
> Interbase has always used qualified symbols to differentiate its
> entrypoints and codes to allow it to coexist with other systems,
> including other systems that don't play by the rules. Firebird

should,

> must, continue this practice. And that means that symbols and code

that

> are not defined by Interbase Software Corporation cannot be prefixed
> with "isc."

Jim, you insist on wrong provision. There is no technical problem on
having two same C/C++ symbols on Win32 in different modules (and in all
other cases except ELF .SO) - I can show you an example (also, I work
closely with front-end writers; they can confirm there is no such
problem exists). In case of ELF .SO nothing can save you - your approach
doesn't work anyway. All symbols (including internal ones - this work is
now in progress) must be changed to get some safety on ELF. This
approach would create unnecessary work for front-end writers (you are
trying to care of them, right?) and even if we implement this, all
public API has to be changed at once, along with creation of wrapper
library for backward compatibility (and I'm not sure if this work really
needs to be done). Horrible mixture of isc_ and fb_ prefixes should
never exist.

We just got rid of gds_ prefixes for constants and made gds_ namespace
engine-internal. I don't want project to go through the same mess one
more time.

Anyway, since all the code is going to pass through Firebird team sieve
I have no problem to change your prefixes to currently correct "isc_"
ones. It is better for you to use "jim_" prefix so it will be easier to
find such code.

> Jim Starkey

Nickolay Samofatov