httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: mod_dav integration
Date Mon, 26 Jun 2000 07:42:08 GMT
On Sun, Jun 25, 2000 at 08:14:01PM -0500, William A. Rowe, Jr. wrote:
> > From: Greg Stein []
> > Sent: Sunday, June 25, 2000 7:33 PM
> > 
> > [...] as it is a new (reasonably-sized) feature, it needs 
> > to passed by people for a vote. I know there are at least
> > three +1 votes for it, so please speak up if you have a veto.
> No objection here whatsoever, provided it remains a module that
> administrators could include or pull at their discression.

Absolutely. Its placement into src/modules/dav/... was intended to exemplify
this point.

> > Second: mod_dav is quite stable, [...] I'm quite comfortable 
> > just dropping it in and doing the 2.0 port, followed by
> > some APR-ization. [...] 
> >
> > Third: if there *are* technical issues with the code, then I 
> > would ask that we fix them after the checkin. I'd like to be 
> > able to check in a pure copy of the mod_dav 1.0 code and then
> > to build up the necessary/requested changes the CVS history.
> 100% agreed, since the history will be important and virtually
> every other source followed a similar route.  Again, as with 
> the early 2.0, I'd strip out the pre-1.0 history if you were 
> thinking of bringing that over... treat it, as it were, as a
> completed starting point.

I had planned to simply "add" the files. I hadn't considered the history
files. Hmm. Since the history is not located in any ASF repository, it might
actually make more sense to bring them over.

Opinions welcome here.

> >   Near term: src/main/http_core.c picks up the 
> >     "LimitXMLRequestBody" directive.
> I have a problem with this, unless other modules will obey the
> exact same setting of this exact directive.  We are -already-
> discussing the CLEANUP of http_core, pulling out mod_cgi crud
> and so on.... we don't need extra mod-specific code in there!!!

I agree with your basic point. This suggestion is simply based on the fact
that other Limit directives are in there. Yes, they should be broken out and
go somewhere else. This would go with them :-)

It is arguably DAV-specific, as the HTTP methods which have an XML body are
all DAV methods. But I could see this being used for limiting SOAP request
bodies (which are pure XML, I believe). And for future HTTP methods... and
for people using experimental/private methods...

> If it is abstract and necessary then fine, but not if this will
> be principally for mod_dav... similar for the other dav_xml...
> stuff, if it -will- be used for many modules, great, if it is
> truly mod_dav specific, then no, they belong in mod_dav.

The XML stuff is intended to be used by other systems. There is nothing
inherently DAV-specific in there. We can't find out what might use it unless
we make it available :-)

If/when we ever get XML-based configuration, then it would use these

> I'll be judging this way, prior to beta 1, if there are any
> lingering if (ap_moddav_symbol()) things in any util_bleh or
> http_core modules, I'll be screaming :)  Since you simply want
> the straight move followed by cleanup, I'll shut up a while.

I'll scream with you :-)

Before any file, symbol, typedef, or macro moves outside of modules/dav/, it
would get the proper prefix. Every public symbol in mod_dav is prefixed by
"dav_" or "DAV_". For the most part, those just change to "ap_" or "AP_".

I'm with you on this: no way should anything in "Apache proper" have any
remnant of attaching to mod_dav. It won't move until then, which is why some
of the items are listed as "near term" ... it may take a bit to shake them
up for proper integration.

> If we can implement the xml pumping in a seperate http_xml base 
> module, I think everyone clamoring for a better http_core will be
> much, much happier.  Then mod_dav can be included after http_xml
> and leverage upon it.

I'm not clear on your suggestion here. Would this be a subject of discussion
for a future pass of changes?


Greg Stein,

View raw message