On Thu, May 31, 2018 at 10:07 AM, Yann Ylavic <ylavic....@gmail.com> wrote:
> On Thu, May 24, 2018 at 8:11 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > > > On Thu, May 24, 2018, 06:34 Eric Covener <cove...@gmail.com> wrote: > >> > >> Despite the directory structure, this was not part of a "module" in > >> the httpd/LoadModule sense. I think it's reasonable to pull it "up" > >> which is simpler then trying to push more stuff down into > >> modules/http/. > > > > [Caviet] > > Note that relocation is a major mmn bump, due to two level namespaces... > > Which isn't usual apparent on flat namespace architectures such as Linux. > > How about: > 1. we move+rename the functions to "server/protocol.c" and have and > the "modules/http/http_etag.c" ones simply call the formers (MINOR > bump). > 2. we then "svn remove" modules/http/http_etag.c and rename back > ap_make_etag_core() and ap_set_etag_core() to their original names > (MAJOR bump, both for namespace and removal of transient _core() > functions). > ? > > That way 1. would be backportable to 2.4.x, and after 2/ trunk in the > state we want it to be. > Does it sound good? > That's entirely workable. We just can't change the exports by-module during the 2.4.* cycle, and the proposal above accomplishes this (but does make backports more of a headache during that transition.) As long as the users' code compiles and links against 2.5.* you have not broken anything, so long as they don't need to change #include's. It would be nice to have a schematic of where stuff belongs. http2_* family modules should obviously have those transport-only semantics. Perhaps evolve transport-only HTTP 1.x http_* semantics into an http1_* module, for easy discard. We could keep mod_http(_*) for all HTTP/*.* protocol encoding, but seeing as this is the httpd server, putting any protocol encoding logic into core (perhaps later into a libhttpd, e.g. http_etag -> util_etag) seems rational.
