You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by rb...@covalent.net on 2000/07/03 03:38:03 UTC
util_dav.c
Why is this file in main? This is a dav specific file, so doesn't it
belong in the modules/dav directory?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: util_dav.c
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Tuesday, July 04, 2000 4:14 AM
>
> ap/ dropped down to something like four files, three of which were also
> threatened to go into APR (hooks, sha1, base64). With the thing dwindling
> like that, people figured "screw it. toss the directly rather than keep it
> for one or two files."
Yes - ap/ (the core apache library) is nearly replaced by APR, and the
rest do NOT belong in APR, but were slated for main.
> If we bang things back around and start shoving stuff over
> there, we can resuscitate the thing.
I'm not against this ... if it is a CONSIDERED solution to a set of
functions - with some definitions of what it should and should not
encompass. A certain APR architect has admitted a lack of 'rules'
or 'standards' for what is/isn't APR - and I am -1 on anyone doing
something similar without such definitions.
> Last comment: we should be very careful about making parts of the utils
> directory optional. Too far in that direction could mean people can't rely
> on certain features to always be present in Apache. "what? the SHA1 stuff
> wasn't compiled in? damn!" :-)
++1 - All libraries aught to be built.
Re: util_dav.c
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jul 04, 2000 at 01:47:52AM -0700, Life is hard, and then you die wrote:
> On Mon, Jul 03, 2000 at 08:50:39AM -0700, rbb@covalent.net wrote:
> > The idea of adding something that *might* be useful later is
> > getting to be a common theme. Main is the wrong spot for things like
> > this. A bunch of functions that are useful for a couple of modules
> > belongs someplace else. Main should be used for functions needed for the
> > base server. Maybe we need a modules/util. This would be a place for
> > modules to store functions that multiple modules can use.
> >
> > I REALLY would like to clean out main to make it easy for new people to
> > contribute.
>
> I wholehartedly agree. IMHO main should only contain the core server stuff -
> all the utils in there, the stuff that used-to-be/is in ap, etc, should
> go into its own directory. This could modules/util, lib/util, or even ap
> (I guess I missed the reason/discussion why ap was supposed to go away).
ap/ dropped down to something like four files, three of which were also
threatened to go into APR (hooks, sha1, base64). With the thing dwindling
like that, people figured "screw it. toss the directly rather than keep it
for one or two files."
If we bang things back around and start shoving stuff over there, we can
resuscitate the thing.
I'm not much for modules/util (since we probably won't dyn-load this stuff).
lib/util would make good sense, though.
What could go in there? Bunch of stuff. The ap/ contents, util_*, probably a
few other things.
Want another possibility? Move the *HTTP* stuff out of main. Create a
mod_http that holds most of that stuff. I mean we have a mod_echo, and can
theoretically handle other protocols via modules... why not turn HTTP in a
true module? Regardless of where the utility stuff goes, I think this would
be a good thing to do.
Yah, I don't think mod_http.c would be rational. It would probably need a
full modules/http/, but still... http_core could become a *real* module
rather than a psuedo thing.
Last comment: we should be very careful about making parts of the utils
directory optional. Too far in that direction could mean people can't rely
on certain features to always be present in Apache. "what? the SHA1 stuff
wasn't compiled in? damn!" :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: util_dav.c
Posted by rb...@covalent.net.
On Tue, 4 Jul 2000, Life is hard, and then you die wrote:
> On Mon, Jul 03, 2000 at 08:50:39AM -0700, rbb@covalent.net wrote:
> >
> > The idea of adding something that *might* be useful later is
> > getting to be a common theme. Main is the wrong spot for things like
> > this. A bunch of functions that are useful for a couple of modules
> > belongs someplace else. Main should be used for functions needed for the
> > base server. Maybe we need a modules/util. This would be a place for
> > modules to store functions that multiple modules can use.
> >
> > I REALLY would like to clean out main to make it easy for new people to
> > contribute.
>
> I wholehartedly agree. IMHO main should only contain the core server stuff -
> all the utils in there, the stuff that used-to-be/is in ap, etc, should
> go into its own directory. This could modules/util, lib/util, or even ap
> (I guess I missed the reason/discussion why ap was supposed to go away).
I think ap is going away because the name wasn't very descriptive. We
really just wanted to move ap to either APR or to it's own library.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: util_dav.c
Posted by "Life is hard, and then you die" <ro...@innovation.ch>.
On Mon, Jul 03, 2000 at 08:50:39AM -0700, rbb@covalent.net wrote:
>
> The idea of adding something that *might* be useful later is
> getting to be a common theme. Main is the wrong spot for things like
> this. A bunch of functions that are useful for a couple of modules
> belongs someplace else. Main should be used for functions needed for the
> base server. Maybe we need a modules/util. This would be a place for
> modules to store functions that multiple modules can use.
>
> I REALLY would like to clean out main to make it easy for new people to
> contribute.
I wholehartedly agree. IMHO main should only contain the core server stuff -
all the utils in there, the stuff that used-to-be/is in ap, etc, should
go into its own directory. This could modules/util, lib/util, or even ap
(I guess I missed the reason/discussion why ap was supposed to go away).
Cheers,
Ronald
Re: util_dav.c
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Jul 03, 2000 at 08:48:45PM -0700, rbb@covalent.net wrote:
>
>
> > Hehe... the naming didn't last nearly as long as I expected. The
> > ever-resourceful Joe Orton posted a patch for this a mere number of hours
> > after this note.
> >
> > Whee!
>
> I still think this file needs to be moved to modules/common. This file is
> not used by the core server, so it doesn't belong in main. Are there
> plans to make the core server ever use these functions?
Yes.
Besides the mod_soap example, I would also consider it for an XML
configuration option.
There seemed to be some consensus on allowing XML for the config and using
"outbound" processors to map various config inputs into a standard form. The
reverse-pressure seemed to focus on loadable modules for config and Joe
Billy Bob installing his thingy-ma-jigger-config-parser.
In other words, here is a scenario that I'd like to see:
*) Suck in config via XML.
*) Use perl scripts or whatever to construct that XML from <config source>,
fed into Apache via a pipe.
*) [maybe?] Use perl or similar to map the old syntax into XML and toss the
old syntax from the core.
I'm not sure about a modules/common/ (or lib/util or whatever) unless we can
identify some other, optional features of the server. Even then, I would be
a bit reluctant because it would imply that third party modules could not
rely on the feature being present. We already have issues today where an
Apache installation doesn't have mod_so, so people can't use apxs and
dynamically install stuff. Then again, the kitchen sink approach is always
appetizing either...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: util_dav.c
Posted by rb...@covalent.net.
> Hehe... the naming didn't last nearly as long as I expected. The
> ever-resourceful Joe Orton posted a patch for this a mere number of hours
> after this note.
>
> Whee!
I still think this file needs to be moved to modules/common. This file is
not used by the core server, so it doesn't belong in main. Are there
plans to make the core server ever use these functions?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: util_dav.c
Posted by Greg Stein <gs...@lyra.org>.
Hehe... the naming didn't last nearly as long as I expected. The
ever-resourceful Joe Orton posted a patch for this a mere number of hours
after this note.
Whee!
-g
On Mon, Jul 03, 2000 at 01:05:47AM -0700, Greg Stein wrote:
> On Sun, Jul 02, 2000 at 10:47:52PM -0500, William A. Rowe, Jr. wrote:
> > > From: rbb@covalent.net [mailto:rbb@covalent.net]
> > > Sent: Sunday, July 02, 2000 9:36 PM
> > >
> > > > Are you talking about util_xml? It is dav-centric now, but
> > > > I think the plan is to work in generic parsing of xml requests.
> > >
> > > Oops, yes util_xml.c. I really think this needs to be moved to
> > > modules/dav. If we need generic parsing of xml requests,
> > > then we can add
> > > it later, taking parts from util_xml.c. This file is a dav file. It
> > > references dav consistently, and if somebody doesn't enable
> > > mod_dav, this
> > > file still gets compiled, but nothing in it is ever used.
> >
> > I've posted the same to Greg, and have his agreement that if these
> > dav-references exist in August he will be screamed at loudly. He
> > concurred, but there is still rework.
> >
> > The issue was to pull in dav in it's present form, and begin the
> > rework within the context of the 2.0 release (for history). There
> > was strong concensus for this approach.
>
> Oh, geez. Did I commit to August? Feh. Those names won't stick around nearly
> that long :-)
>
> s/dav/ap/ :-)
>
>
> Actually, that file is problematic right now because it has references to
> the DAV code. Grr. (since the latter is optional, bad juju happens if
> util_xml doesn't find them to link to)
>
> Some thought needed here.
>
> Ryan's point about them not being used *now* is true. However, the intent is
> that modules that want to use XML have the facilities available. For
> example, a mod_soap would make great use of this stuff.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
--
Greg Stein, http://www.lyra.org/
RE: util_dav.c
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Monday, July 03, 2000 10:51 AM
>
> The idea of adding something that *might* be useful later is
> getting to be a common theme. Main is the wrong spot for things like
> this. A bunch of functions that are useful for a couple of modules
> belongs someplace else. Main should be used for functions needed for the
> base server.
> Maybe we need a modules/util. This would be a place for
> modules to store functions that multiple modules can use.
++1
> I REALLY would like to clean out main to make it easy for new
> people to
> contribute.
>
> Ryan
>
> ______________________________________________________________
> _________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> --------------------------------------------------------------
> -----------------
>
Re: util_dav.c
Posted by rb...@covalent.net.
> Actually, that file is problematic right now because it has references to
> the DAV code. Grr. (since the latter is optional, bad juju happens if
> util_xml doesn't find them to link to)
>
> Some thought needed here.
>
> Ryan's point about them not being used *now* is true. However, the intent is
> that modules that want to use XML have the facilities available. For
> example, a mod_soap would make great use of this stuff.
The idea of adding something that *might* be useful later is
getting to be a common theme. Main is the wrong spot for things like
this. A bunch of functions that are useful for a couple of modules
belongs someplace else. Main should be used for functions needed for the
base server. Maybe we need a modules/util. This would be a place for
modules to store functions that multiple modules can use.
I REALLY would like to clean out main to make it easy for new people to
contribute.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: util_dav.c
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Jul 02, 2000 at 10:47:52PM -0500, William A. Rowe, Jr. wrote:
> > From: rbb@covalent.net [mailto:rbb@covalent.net]
> > Sent: Sunday, July 02, 2000 9:36 PM
> >
> > > Are you talking about util_xml? It is dav-centric now, but
> > > I think the plan is to work in generic parsing of xml requests.
> >
> > Oops, yes util_xml.c. I really think this needs to be moved to
> > modules/dav. If we need generic parsing of xml requests,
> > then we can add
> > it later, taking parts from util_xml.c. This file is a dav file. It
> > references dav consistently, and if somebody doesn't enable
> > mod_dav, this
> > file still gets compiled, but nothing in it is ever used.
>
> I've posted the same to Greg, and have his agreement that if these
> dav-references exist in August he will be screamed at loudly. He
> concurred, but there is still rework.
>
> The issue was to pull in dav in it's present form, and begin the
> rework within the context of the 2.0 release (for history). There
> was strong concensus for this approach.
Oh, geez. Did I commit to August? Feh. Those names won't stick around nearly
that long :-)
s/dav/ap/ :-)
Actually, that file is problematic right now because it has references to
the DAV code. Grr. (since the latter is optional, bad juju happens if
util_xml doesn't find them to link to)
Some thought needed here.
Ryan's point about them not being used *now* is true. However, the intent is
that modules that want to use XML have the facilities available. For
example, a mod_soap would make great use of this stuff.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
RE: util_dav.c
Posted by rb...@covalent.net.
> I've posted the same to Greg, and have his agreement that if these
> dav-references exist in August he will be screamed at loudly. He
> concurred, but there is still rework.
>
> The issue was to pull in dav in it's present form, and begin the
> rework within the context of the 2.0 release (for history). There
> was strong concensus for this approach.
OK, but it's not just the references to dav. AFAICT, most of the
functions in that file are DAV specific functions, and I am having a hard
time seeing how those functions will be used outside of DAV, at least in
the near future.
I'll wait till August. :-)
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: util_dav.c
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: rbb@covalent.net [mailto:rbb@covalent.net]
> Sent: Sunday, July 02, 2000 9:36 PM
>
> > Are you talking about util_xml? It is dav-centric now, but
> > I think the plan is to work in generic parsing of xml requests.
>
> Oops, yes util_xml.c. I really think this needs to be moved to
> modules/dav. If we need generic parsing of xml requests,
> then we can add
> it later, taking parts from util_xml.c. This file is a dav file. It
> references dav consistently, and if somebody doesn't enable
> mod_dav, this
> file still gets compiled, but nothing in it is ever used.
I've posted the same to Greg, and have his agreement that if these
dav-references exist in August he will be screamed at loudly. He
concurred, but there is still rework.
The issue was to pull in dav in it's present form, and begin the
rework within the context of the 2.0 release (for history). There
was strong concensus for this approach.
Bill
RE: util_dav.c
Posted by rb...@covalent.net.
> Are you talking about util_xml? It is dav-centric now, but
> I think the plan is to work in generic parsing of xml requests.
Oops, yes util_xml.c. I really think this needs to be moved to
modules/dav. If we need generic parsing of xml requests, then we can add
it later, taking parts from util_xml.c. This file is a dav file. It
references dav consistently, and if somebody doesn't enable mod_dav, this
file still gets compiled, but nothing in it is ever used.
Ryan
>
> Keith
>
> -----Original Message-----
> Subject: util_dav.c
>
> Why is this file in main? This is a dav specific file, so doesn't it
> belong in the modules/dav directory?
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: util_dav.c
Posted by Keith Wannamaker <Ke...@Wannamaker.org>.
Are you talking about util_xml? It is dav-centric now, but
I think the plan is to work in generic parsing of xml requests.
Keith
-----Original Message-----
Subject: util_dav.c
Why is this file in main? This is a dav specific file, so doesn't it
belong in the modules/dav directory?