httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: help with Expat patch
Date Mon, 08 Feb 1999 10:52:00 GMT
Ralf S. Engelschall wrote:
> In article <> you wrote:
> > It appears to be working fine, with all the fancy RULE stuff (so I can
> > have RULE_EXPAT=yes in my libdav.module). (of course, suggestions for
> > change are welcome :-)
> > However, if I compile mod_dav as a dynamically-loaded module, then it
> > won't load, because it can't find the Expat symbols. (sigh)  I know this
> > has to do with order of loading or maybe that the Expat stuff didn't get
> > pulled into httpd (no ref to it from there).
> Just putting in Expat as a library is not enough. What you should do is to
> additionally provide a thin Apache layer on top if it which is part of the
> core code, i.e. some ap_expat_xxxx() functions which call the expat functions.
> This has two benefits: It's a clean API where we can get control between
> modules and expat and it solves the DSO problem you mentioned.

There are 25 functions exported by Expat, along with a good number of
typedefs and constants. Leaving the typedefs and constants alone, and
just covering the 25 functions would seem a bit silly, IMO. While I
certainly understand the DSO benefit, I really do not see your "clean
API" point. The API will look just like Expat (which is already quite
clean). I don't understand the benefit. I could certainly select the
subset that mod_dav uses, but I don't believe that is Right either.

However, were I to provide the layer that I use in DAV for the XML
handling (essentially, it constructs a very useful tree structure), then
I might understand, since that would be just a function or two wide.

I'm more than willing to donate my XML handling code, but I think that
would be a whole different thing for the Group to consider (compared to
simply plugging in Expat). Personally, I think the extra layer/code is
preferable, since any module is going to need something similar, and it
would allow different parsers to be plugged in "beneath" this layer (for
example, I know some people would need to replace Expat due to the MPL
(v1 or v2)).

> > also, my patch to Configuration.apaci seemed to have disappeared. It
> > added a "Rule EXPAT=no" in there with a bit of doc. Looks like that file
> > gets rewritten from somewhere?
> Configuration.apaci is _generated_ by APACI on-the-fly. Your
> patch should be applied to Configuration.tmpl, of course.

*nod*. thanx. I found this a while after sending the note, but figured I
didn't need to spam the group again with an email saying so :-)


Greg Stein,

View raw message