[xml] libxml2/libxslt: global variables considered harmful

[Michael Stahl <Michael X Stahl Oracle com>]

hi all,

i've just remembered that i've long wanted to write a rant on how evil the
global variables in libxml2/libxslt are.

i've come to this conclusion with this bug:
http://qa.openoffice.org/issues/show_bug.cgi?id=110523

what happens here is that there is now some new code that uses the
"redland" and "raptor" libraries to parse RDF files.
"raptor" uses libxml2 and libxslt to parse various different formats.
by simply initializing the "raptor" library, a completely different part
of our enormous, complex, bloated system was broken in a catastrophic way:
the online help browser would no longer display any help, just a white screen.

the online help has nothing at all to do with RDF, but it also uses the
libxslt library.
initializing raptor sets some global variable in libxslt that prevents
opening file:// urls, and that breaks the online help.

in a large and complex system it's generally impossible to answer
questions like "where is library $foo used?";  thus "hidden communication
channels" that can be accidentally invoked (like global variables) are a
huge PITA.
actually, read-only global data is not a problem;  i think it is only a
problem if the global variables can be changed by client code.

now if you look at the interface of the redland library you can see one
approach to solve this problem:
redland defines a "redland_world" struct, and this contains all its
"global state".
http://librdf.org/docs/api/redland-world.html

all redland public methods either take a "librdf_world" parameter, or some
parameter that contains a pointer to a librdf_world.
then there are functions to create, init and destroy librdf_worlds.
so different clients of the redland library are (hopefully) completely
independent.

the only problem is that redland depends on other libraries, and likes to
call their de-initialization functions when freeing a librdf_world  :(

IMHO such a design would also be possible for libxml2/libxslt, but of
course this would be an incompatible interface change.
usually there isn't much enthusiasm for that kind of thing  :)

but if there ever is an opportunity for a libxml3, _please_ get rid of
global variables.

regards,
 michael

-- 
"UTF-16 is the devil's work." -- Robert O'Callahan