Re: cvs commit: apache-1.3/src/lib/expat-lite xmlparse.c xmltok.c xmltok.h xmltok_impl.c

[Brian Behlendorf <br...@hyperreal.org>]

On 2 Jun 1999 rse@hyperreal.org wrote:
> rse         99/06/02 00:15:06
> 
>   Modified:    src/lib/expat-lite xmlparse.c xmltok.c xmltok.h
>                         xmltok_impl.c
>   Log:
>   Various cleanups to the unclean expat sources to
>   make them at least compile without warnings...

What mechanism should we use to make sure that changes to this code are
reflected back upstream to Clark, and conversely, that we are always able
to pull down new versions of expat?

Perhaps we should consider using this as an external library (a la
pthreads in apache-2.0) instead of an imported block of code?

	Brian

Re: cvs commit: apache-1.3/src/lib/expat-lite xmlparse.c xmltok.c xmltok.h xmltok_impl.c

[Greg Stein <gs...@lyra.org>]

Brian Behlendorf wrote:
>...
> What mechanism should we use to make sure that changes to this code are
> reflected back upstream to Clark, and conversely, that we are always able
> to pull down new versions of expat?

I'm more than happy to continue coordinating this (sending patches and
applying). I figured I signed up the moment I checked it in :-). I've
already sent the patch to Jim Clark.

Regarding putting in new versions: I wrote a document in that directory
detailing what we did (the subset and any actual changes).

Note that we don't (strictly) need to track Expat. We didn't with
HSREGEX. We need something that works, more than needing new features.
i.e. we apply bug fixes, but we can surely punt on new-feature releases.

Regardless: it won't be troublesome to deal with this.

> Perhaps we should consider using this as an external library (a la
> pthreads in apache-2.0) instead of an imported block of code?

I thought about this quite a bit. Unfortunately, we have mutually
exclusive needs here: including it into Apache (and building it there)
typically means it *won't* be in the system lib directories (e.g.
LD_LIBRARY_PATH). To use libexpat.so it must be in the system path, or
we must manually load it (which makes coding against it a *real* pain).

Summary: to easily provide dependable, always-there XML parsing services
to Apache code/modules, we must ship it since it isn't normally part of
users' systems. This in turn implies it is difficult to use it as a
dynamically loaded library.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/