You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Fritsch <sf...@sfritsch.de> on 2011/12/03 00:48:19 UTC
Are we there yet?
Hi,
where are we WRT 2.4?
Blockers:
mod_proxy_scgi.c needs to be fixed for compilation with C89 (easy)
The only blocker left in STATUS is this:
* Modules that are not ready for production use must be removed.
The same for modules without documentation.
I think we have already removed the obvious candidates WRT maturity.
About documentation, docs/STATUS has this:
- modules docs
- the follwing modules added since 2.2 lack documentation
- mod_watchdog
- mod_heartbeat
- mod_heartmonitor
- mod_lbmethod_heartbeat
- mod_socache_dbm
- mod_socache_memcache
- mod_socache_shmcb
Do we want to remove any of these modules?
The unique tags for log messages change is waiting for backport to
2.4. But if people would want to let it sit in trunk a bit and wait
for 2.4.1, that would be fine with me, too.
Anything else? Jim, do you consider your mod_proxy* changes finished?
Do you think they are well enough tested for an instant 2.4.0?
Graham has suggested some more refactoring for mod_proxy*. Would
certainly be nice but not a blocker.
Do we need another beta? Or just roll an release candidate tarball,
have people test a bit, and if it's good, tag 2.4.0?
Cheers,
Stefan
Re: Are we there yet?
Posted by Graham Leggett <mi...@sharp.fm>.
On 04 Dec 2011, at 6:16 AM, Gregg L. Smith wrote:
> What seems to have not made it in there .. I am not against adding them to mod_ssl, since I see no other use for these specific modules.
I see tonnes of uses for these modules. We already have mod_authn_socache in v2.4 right now, and mod_disk_cache was renamed mod_cache disk to pave the way for the existence of mod_cache_socache to replace mod_mem_cache.
Having a general purpose key/value store interface is a very useful thing.
> I like that stuff has been ripped out of core and modularized , that is, what I believe, makes the 2.4 footprint so small, load what you need and nothing more.
+1.
Regards,
Graham
--
Re: Are we there yet?
Posted by Nick Kew <ni...@webthing.com>.
On 4 Dec 2011, at 04:16, Gregg L. Smith wrote:
>
> What seems to have not made it in there .. I am not against adding them to mod_ssl, since I see no other use for these specific modules.
mod_authn_socache is probably the first other module to benefit from separating out
this functionality from mod_ssl.
But I've also recommended it to a number of third-party developers who have asked
about similar tasks. We don't know how many applications there are out there.
--
Nick Kew
Re: Are we there yet?
Posted by "Gregg L. Smith" <gl...@gknw.net>.
On 12/3/2011 7:54 PM, Gregg L. Smith wrote:
> On 12/3/2011 2:28 PM, William A. Rowe Jr. wrote:
>> On 12/3/2011 1:32 AM, Gregg L. Smith wrote:
>>> On 12/2/2011 3:48 PM, Stefan Fritsch wrote:
>>>> - the follwing modules added since 2.2 lack documentation
>>>
>>>> - mod_socache_dbm
>>>> - mod_socache_memcache
>>>> - mod_socache_shmcb
>>>
>>> These are required for SSL AFIAK, they must stay! Mentioned in the
>>> mod_ssl docks should be
>>> sufficient IMHO.
>>
>> It isn't. Someone trimming their LoadModule lines will undoubtedly
>> hit the wall trying to figure out why they couldn't just switch from
>> memcache or dbm back to shmcb. Someone else will break there server
>> simply removing unfamiliar modules from the list, particularly one
>> which appears nowhere in the ASF HTTP Server module documents lists.
>
> Which is why I said mention them in the mod_ssl docs
>
> Say under the SSLSessionCache Directive
>
> For dbm, add a note that mod_socache_dbm is required.
> for .. well ... I see shm .. assuming "shmdb" tho I use and have
> configured as "shmdb", that mod_socache_shmdb is required .. etc. I
> see nothing for memcache .. so looks like this needs some updating
> before GA
What seems to have not made it in there .. I am not against adding them
to mod_ssl, since I see no other use for these specific modules. I like
that stuff has been ripped out of core and modularized , that is, what I
believe, makes the 2.4 footprint so small, load what you need and
nothing more.
Cheers,
Gregg
Re: Are we there yet?
Posted by "Gregg L. Smith" <gl...@gknw.net>.
On 12/3/2011 2:28 PM, William A. Rowe Jr. wrote:
> On 12/3/2011 1:32 AM, Gregg L. Smith wrote:
>> On 12/2/2011 3:48 PM, Stefan Fritsch wrote:
>>> - the follwing modules added since 2.2 lack documentation
>>
>>> - mod_socache_dbm
>>> - mod_socache_memcache
>>> - mod_socache_shmcb
>>
>> These are required for SSL AFIAK, they must stay! Mentioned in the
>> mod_ssl docks should be
>> sufficient IMHO.
>
> It isn't. Someone trimming their LoadModule lines will undoubtedly
> hit the wall trying to figure out why they couldn't just switch from
> memcache or dbm back to shmcb. Someone else will break there server
> simply removing unfamiliar modules from the list, particularly one
> which appears nowhere in the ASF HTTP Server module documents lists.
Which is why I said mention them in the mod_ssl docs
Say under the SSLSessionCache Directive
For dbm, add a note that mod_socache_dbm is required.
for .. well ... I see shm .. assuming "shmdb" tho I use and have
configured as "shmdb", that mod_socache_shmdb is required .. etc. I see
nothing for memcache .. so looks like this needs some updating before GA
However I am looking at the trunk docs ... since 2.4 is not online yet
.. in the URL I assume they will be eventually be
Cheers,
Gregg
Re: Are we there yet?
Posted by Graham Leggett <mi...@sharp.fm>.
On 04 Dec 2011, at 12:28 AM, William A. Rowe Jr. wrote:
> It isn't. Someone trimming their LoadModule lines will undoubtedly
> hit the wall trying to figure out why they couldn't just switch from
> memcache or dbm back to shmcb. Someone else will break there server
> simply removing unfamiliar modules from the list, particularly one
> which appears nowhere in the ASF HTTP Server module documents lists.
This is definitely a problem, but the changes to the error messages should make it clear to end users what their course of action should be. We're a modular server, adding a module to get something is normal.
> This, and the mod_slotmem_* objects, really make lousy modules.
>
> I can understand wanting to extend socache and slotmem into much
> more complex or experimental backend stores. Extensibility is good.
> But for the time being, and for this fundamental set...
>
> can we please trash all 6 "modules" and add the code into core?
> It seems to me that even apreq extensions are in a more usable,
> documented state than these... and we refuse to incorporate it.
> I think we got things backwards.
This is just moving the furniture though, it doesn't solve the core problem, which is that they need to be documented (and the API wrong-ness you've pointed out needs to be fixed).
Regards,
Graham
--
Re: Are we there yet?
Posted by Graham Leggett <mi...@sharp.fm>.
On 04 Dec 2011, at 3:27 AM, Nick Kew wrote:
> We have http://httpd.apache.org/docs/2.4/socache.html
>
> In the absence of actual module pages, a solution would be to create the
> URLs for them, with redirection to that page. Add appropriate links and
> they're well-documented for someone reading TFM.
+1.
> Can we please do no such thing?
>
> Maybe for 2.6 they could take on something more like the DBD
> architecture: a generic mod_socache and different backends with
> a different load mechanism. If anyone feels inspired to hack it.
+1.
Regards,
Graham
--
Re: Are we there yet?
Posted by Nick Kew <ni...@webthing.com>.
On 3 Dec 2011, at 22:28, William A. Rowe Jr. wrote:
> On 12/3/2011 1:32 AM, Gregg L. Smith wrote:
>> On 12/2/2011 3:48 PM, Stefan Fritsch wrote:
>>> - the follwing modules added since 2.2 lack documentation
>>
>>> - mod_socache_dbm
>>> - mod_socache_memcache
>>> - mod_socache_shmcb
>>
>> These are required for SSL AFIAK, they must stay! Mentioned in the mod_ssl docks should be
>> sufficient IMHO.
>
> It isn't. Someone trimming their LoadModule lines
We have http://httpd.apache.org/docs/2.4/socache.html
In the absence of actual module pages, a solution would be to create the
URLs for them, with redirection to that page. Add appropriate links and
they're well-documented for someone reading TFM.
> can we please trash all 6 "modules" and add the code into core?
Can we please do no such thing?
Maybe for 2.6 they could take on something more like the DBD
architecture: a generic mod_socache and different backends with
a different load mechanism. If anyone feels inspired to hack it.
--
Nick Kew
Re: Are we there yet?
Posted by "Gregg L. Smith" <gl...@gknw.net>.
On 12/4/2011 1:02 AM, Stefan Fritsch wrote:
> On Saturday 03 December 2011, William A. Rowe Jr. wrote:
>> On 12/3/2011 1:32 AM, Gregg L. Smith wrote:
>>> On 12/2/2011 3:48 PM, Stefan Fritsch wrote:
>>>> - the follwing modules added since 2.2 lack documentation
>>>>
>>>> - mod_socache_dbm
>>>> - mod_socache_memcache
>>>> - mod_socache_shmcb
>>> These are required for SSL AFIAK, they must stay! Mentioned in
>>> the mod_ssl docks should be sufficient IMHO.
>> It isn't. Someone trimming their LoadModule lines will undoubtedly
>> hit the wall trying to figure out why they couldn't just switch
>> from memcache or dbm back to shmcb. Someone else will break there
>> server simply removing unfamiliar modules from the list,
>> particularly one which appears nowhere in the ASF HTTP Server
>> module documents lists.
>>
>> This, and the mod_slotmem_* objects, really make lousy modules.
> Isn't the answer to this that all consumers of slotmem and socache
> should simply point to the mod_slotmem_*/mod_socache_* modules in the
> error message if the configured provider is not found? Then the user
> would immediately know that another module is required.
+1, great idea
Re: Are we there yet?
Posted by Graham Leggett <mi...@sharp.fm>.
On 04 Dec 2011, at 11:02 AM, Stefan Fritsch wrote:
> Isn't the answer to this that all consumers of slotmem and socache
> should simply point to the mod_slotmem_*/mod_socache_* modules in the
> error message if the configured provider is not found? Then the user
> would immediately know that another module is required.
+1.
Regards,
Graham
--
Re: Are we there yet?
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Saturday 03 December 2011, William A. Rowe Jr. wrote:
> On 12/3/2011 1:32 AM, Gregg L. Smith wrote:
> > On 12/2/2011 3:48 PM, Stefan Fritsch wrote:
> >> - the follwing modules added since 2.2 lack documentation
> >>
> >> - mod_socache_dbm
> >> - mod_socache_memcache
> >> - mod_socache_shmcb
> >
> > These are required for SSL AFIAK, they must stay! Mentioned in
> > the mod_ssl docks should be sufficient IMHO.
>
> It isn't. Someone trimming their LoadModule lines will undoubtedly
> hit the wall trying to figure out why they couldn't just switch
> from memcache or dbm back to shmcb. Someone else will break there
> server simply removing unfamiliar modules from the list,
> particularly one which appears nowhere in the ASF HTTP Server
> module documents lists.
>
> This, and the mod_slotmem_* objects, really make lousy modules.
Isn't the answer to this that all consumers of slotmem and socache
should simply point to the mod_slotmem_*/mod_socache_* modules in the
error message if the configured provider is not found? Then the user
would immediately know that another module is required.
Re: Are we there yet?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 12/3/2011 1:32 AM, Gregg L. Smith wrote:
> On 12/2/2011 3:48 PM, Stefan Fritsch wrote:
>> - the follwing modules added since 2.2 lack documentation
>
>> - mod_socache_dbm
>> - mod_socache_memcache
>> - mod_socache_shmcb
>
> These are required for SSL AFIAK, they must stay! Mentioned in the mod_ssl docks should be
> sufficient IMHO.
It isn't. Someone trimming their LoadModule lines will undoubtedly
hit the wall trying to figure out why they couldn't just switch from
memcache or dbm back to shmcb. Someone else will break there server
simply removing unfamiliar modules from the list, particularly one
which appears nowhere in the ASF HTTP Server module documents lists.
This, and the mod_slotmem_* objects, really make lousy modules.
I can understand wanting to extend socache and slotmem into much
more complex or experimental backend stores. Extensibility is good.
But for the time being, and for this fundamental set...
can we please trash all 6 "modules" and add the code into core?
It seems to me that even apreq extensions are in a more usable,
documented state than these... and we refuse to incorporate it.
I think we got things backwards.
Bill
Re: Are we there yet?
Posted by Mladen Turk <mt...@apache.org>.
On 12/03/2011 08:32 AM, Gregg L. Smith wrote:
> On 12/2/2011 3:48 PM, Stefan Fritsch wrote:
>> - modules docs
>> - the follwing modules added since 2.2 lack documentation
>> - mod_watchdog
>> - mod_heartbeat
>> - mod_heartmonitor
>> - mod_lbmethod_heartbeat
> I vote these off the Windows boat, mod_watchdog crashes the child processes on Win and is basically required for the rest of them, in a round about way. I even asked Steffen at Apache Lounge to check it for me. I have more detail, but I have spoken up
> about it long ago and I have seen no movement from original author. However, if someone wants to know, feel free to ask.
>
If its crashing it should be fixed. There is nothing in that
module that would crash 'by-design' so its probably some
bug introduced later after my initial commit.
Give me couple of days and I'll fix the module, and
write some docs.
Regards
--
^TM
Re: Are we there yet?
Posted by Graham Leggett <mi...@sharp.fm>.
On 03 Dec 2011, at 9:32 AM, Gregg L. Smith wrote:
>> - modules docs
>> - the follwing modules added since 2.2 lack documentation
>> - mod_watchdog
>> - mod_heartbeat
>> - mod_heartmonitor
>> - mod_lbmethod_heartbeat
> I vote these off the Windows boat, mod_watchdog crashes the child processes on Win and is basically required for the rest of them, in a round about way. I even asked Steffen at Apache Lounge to check it for me. I have more detail, but I have spoken up about it long ago and I have seen no movement from original author. However, if someone wants to know, feel free to ask.
+1.
Regards,
Graham
--
Re: Are we there yet?
Posted by "Gregg L. Smith" <gl...@gknw.net>.
On 12/2/2011 3:48 PM, Stefan Fritsch wrote:
> - modules docs
> - the follwing modules added since 2.2 lack documentation
> - mod_watchdog
> - mod_heartbeat
> - mod_heartmonitor
> - mod_lbmethod_heartbeat
I vote these off the Windows boat, mod_watchdog crashes the child
processes on Win and is basically required for the rest of them, in a
round about way. I even asked Steffen at Apache Lounge to check it for
me. I have more detail, but I have spoken up about it long ago and I
have seen no movement from original author. However, if someone wants
to know, feel free to ask.
> - mod_socache_dbm
> - mod_socache_memcache
> - mod_socache_shmcb
These are required for SSL AFIAK, they must stay! Mentioned in the
mod_ssl docks should be sufficient IMHO.
Cheers,
Gregg
Re: Are we there yet?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
I'd like to see us ship the bundled apr sources (well, I'd like to
see NO bundled apr sources, but...) to include the APR_HAS_IPV6 for
our windows apr.hw, given that all win platforms supported /today/
have support, and it works out quite well.
Of course it's a deep intrinsic change in the build (something that
didn't have to happen, but c'est la vie)... and would be incompatible
for with older httpd's and some third party modules.
To mark the auspicious occasion, what would folks think of shifting
to apr 1.5 so that post-1.4 is the dividing line, for simplicities
sake? Or, other suggestions about bridging that divide?
Re: Are we there yet?
Posted by Graham Leggett <mi...@sharp.fm>.
On 03 Dec 2011, at 1:48 AM, Stefan Fritsch wrote:
> Graham has suggested some more refactoring for mod_proxy*. Would
> certainly be nice but not a blocker.
I have harvested the low hanging fruit from mod_proxy, the next bit of refactoring will take a while and shouldn't hold up v2.4.
Regards,
Graham
--
Re: Are we there yet?
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> On 12/4/2011 5:02 PM, Noel Butler wrote:
> > On Sun, 2011-12-04 at 09:47 -0500, Jim Jagielski wrote:
> >> On Dec 2, 2011, at 6:48 PM, Stefan Fritsch wrote:
> >>
> >> > Hi,
> >> >
> >> > where are we WRT 2.4?
> >> >
> >>
> >> There seems to be a lot of renewed effort in getting 2.4/trunk is
> >> a
> >> really releasable state, which is all Goodness. Ideally, I'd like
> >> to release 2.4.0 before the end of the year, but starting off
> >> 2012 with a new httpd release also makes some sense as well.
> >>
> >
> > +1 for 2012, can't see too many admins upgrading to a new major
> > version with mere weeks
> > till festive season break, and in some countries, that's a long
> > break.
>
> Then perhaps we've already arrived at 2.4.1 by the time they attack
> it.
> That's not exactly a bad thing. We want to push forward quickly.
> Just
> not rushed :)
+1 - most admins won't install a .0 release anyway ;)
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: Are we there yet?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 12/4/2011 5:02 PM, Noel Butler wrote:
> On Sun, 2011-12-04 at 09:47 -0500, Jim Jagielski wrote:
>> On Dec 2, 2011, at 6:48 PM, Stefan Fritsch wrote:
>>
>> > Hi,
>> >
>> > where are we WRT 2.4?
>> >
>>
>> There seems to be a lot of renewed effort in getting 2.4/trunk is a
>> really releasable state, which is all Goodness. Ideally, I'd like
>> to release 2.4.0 before the end of the year, but starting off
>> 2012 with a new httpd release also makes some sense as well.
>>
>
> +1 for 2012, can't see too many admins upgrading to a new major version with mere weeks
> till festive season break, and in some countries, that's a long break.
Then perhaps we've already arrived at 2.4.1 by the time they attack it.
That's not exactly a bad thing. We want to push forward quickly. Just
not rushed :)
Re: Are we there yet?
Posted by Noel Butler <no...@ausics.net>.
On Sun, 2011-12-04 at 09:47 -0500, Jim Jagielski wrote:
> On Dec 2, 2011, at 6:48 PM, Stefan Fritsch wrote:
>
> > Hi,
> >
> > where are we WRT 2.4?
> >
>
> There seems to be a lot of renewed effort in getting 2.4/trunk is a
> really releasable state, which is all Goodness. Ideally, I'd like
> to release 2.4.0 before the end of the year, but starting off
> 2012 with a new httpd release also makes some sense as well.
>
+1 for 2012, can't see too many admins upgrading to a new major version
with mere weeks till festive season break, and in some countries, that's
a long break.
Re: Are we there yet?
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Sunday 04 December 2011, Jim Jagielski wrote:
> I also
> need to look at the event changes as well in trunk to see if
> they are in 2.4.0 as well (or if they are something we could
> easily add post 2.4.0)...
The event changes in trunk are not ready for 2.4, see
http://mail-archives.apache.org/mod_mbox/httpd-
dev/201111.mbox/%3CCAHSOX_C872kk7HWxfaeiEsHQm_2QVJDYjBajkg5RXjaBtx4%2BJQ%40mail.gmail.com%3E
But I think it should be possible to backport them post-GA.
Re: Are we there yet?
Posted by Mladen Turk <mt...@apache.org>.
On 12/04/2011 07:25 PM, Graham Leggett wrote:
> On 04 Dec 2011, at 8:03 PM, Mladen Turk wrote:
>
>>> Let's shoot for an RC1 this week. I'll RM.
>>
>> Do we have bundled apr/apr-util versions defined?
>
> Ideally we want apr-util v1.4.0, which is yet to be released. I've proposed to RM a release of apr-util this weekend or next week to the APR project and haven't had any objections, am still happy to do so.
>
So the lazy consensus rule applies. Feel free to cut the release.
Regards
--
^TM
Re: Are we there yet?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 4, 2011, at 1:25 PM, Graham Leggett wrote:
> On 04 Dec 2011, at 8:03 PM, Mladen Turk wrote:
>
>>> Let's shoot for an RC1 this week. I'll RM.
>>
>> Do we have bundled apr/apr-util versions defined?
>
> Ideally we want apr-util v1.4.0, which is yet to be released. I've proposed to RM a release of apr-util this weekend or next week to the APR project and haven't had any objections, am still happy to do so.
Yeah, apu-1.4.0 would be the best choice. With my APR hat on, +1 for
the release ;)
Re: Are we there yet?
Posted by Graham Leggett <mi...@sharp.fm>.
On 04 Dec 2011, at 8:03 PM, Mladen Turk wrote:
>> Let's shoot for an RC1 this week. I'll RM.
>
> Do we have bundled apr/apr-util versions defined?
Ideally we want apr-util v1.4.0, which is yet to be released. I've proposed to RM a release of apr-util this weekend or next week to the APR project and haven't had any objections, am still happy to do so.
Regards,
Graham
--
Re: Are we there yet?
Posted by Mladen Turk <mt...@apache.org>.
On 12/04/2011 06:37 PM, Jim Jagielski wrote:
>
>
> Let's shoot for an RC1 this week. I'll RM.
Do we have bundled apr/apr-util versions defined?
Regards
--
^TM
Re: Are we there yet?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 4, 2011, at 10:41 AM, Stefan Fritsch wrote:
> On Sun, 4 Dec 2011, Jim Jagielski wrote:
>> There seems to be a lot of renewed effort in getting 2.4/trunk is a
>> really releasable state, which is all Goodness. Ideally, I'd like
>> to release 2.4.0 before the end of the year, but starting off
>> 2012 with a new httpd release also makes some sense as well.
>
> I was kind of hoping for GA before Christmas...
>
>> With all the changes, I would like to have another 'beta' release
>> simply to try to work out any remaining issues, but my fear is
>> that this would also encourage a lot of rework rather than
>> polishing (if you get my drift). So tagging as a RC puts us in
>> the more correct state of mind.
>
> +1 for a RC ASAP. Do you have time to RM again?
>
> Would we name that RC 2.4.0 or would we release 2.3.16 from the 2.4.x branch?
>
> We could also consider putting the focus more on polishing by making API changes and large refactorings review-then-commit. Probably with the exception of the proxy/slotmem plans that were already put forward on the list.
>
> I would also like to know what more people think about the error message tag thing? AAUI Rich, Graham, and myself are for including it in 2.4 now, while Nick prefers to wait. If we decide to wait, it should maybe be reverted from trunk, too, to make merging of commits to 2.4 easier.
>
Let's be honest... if we punt to trunk, it'll be another several years before
people see it.
Let's do it now. Let's make 2.4 the best it can be... I also
need to look at the event changes as well in trunk to see if
they are in 2.4.0 as well (or if they are something we could
easily add post 2.4.0)...
Let's shoot for an RC1 this week. I'll RM.
Re: Are we there yet?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 4, 2011, at 10:52 AM, Graham Leggett wrote:
> On 04 Dec 2011, at 5:41 PM, Stefan Fritsch wrote:
>
>> I was kind of hoping for GA before Christmas...
>
> +1.
>
>> We could also consider putting the focus more on polishing by making API changes and large refactorings review-then-commit. Probably with the exception of the proxy/slotmem plans that were already put forward on the list.
>
> The only thing we should be changing right now apart from low hanging fruit is API changes, if an API is genuinely broken it needs to get fixed.
>
> We need to draw a line though, mod_proxy could do with a serious refactor but that has missed the boat from v2.4 - what is important though it to make sure that during the life of httpd v2.4, backporting isn't that onerous to do.
>
++1... What I've been working on re mod_proxy is ensuring that
the API for 2.4.0 is enough to allow us to support that refactoring...
Re: Are we there yet?
Posted by Graham Leggett <mi...@sharp.fm>.
On 04 Dec 2011, at 5:41 PM, Stefan Fritsch wrote:
> I was kind of hoping for GA before Christmas...
+1.
> We could also consider putting the focus more on polishing by making API changes and large refactorings review-then-commit. Probably with the exception of the proxy/slotmem plans that were already put forward on the list.
The only thing we should be changing right now apart from low hanging fruit is API changes, if an API is genuinely broken it needs to get fixed.
We need to draw a line though, mod_proxy could do with a serious refactor but that has missed the boat from v2.4 - what is important though it to make sure that during the life of httpd v2.4, backporting isn't that onerous to do.
> I would also like to know what more people think about the error message tag thing? AAUI Rich, Graham, and myself are for including it in 2.4 now, while Nick prefers to wait. If we decide to wait, it should maybe be reverted from trunk, too, to make merging of commits to 2.4 easier.
I think it should go into both, or none at all. Backporting changes will becomes a serious pain if something as widely deployed as log messages are different between v2.4 and trunk.
Regards,
Graham
--
Re: Are we there yet?
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Sun, 4 Dec 2011, Jim Jagielski wrote:
> There seems to be a lot of renewed effort in getting 2.4/trunk is a
> really releasable state, which is all Goodness. Ideally, I'd like
> to release 2.4.0 before the end of the year, but starting off
> 2012 with a new httpd release also makes some sense as well.
I was kind of hoping for GA before Christmas...
> With all the changes, I would like to have another 'beta' release
> simply to try to work out any remaining issues, but my fear is
> that this would also encourage a lot of rework rather than
> polishing (if you get my drift). So tagging as a RC puts us in
> the more correct state of mind.
+1 for a RC ASAP. Do you have time to RM again?
Would we name that RC 2.4.0 or would we release 2.3.16 from the 2.4.x
branch?
We could also consider putting the focus more on polishing by making API
changes and large refactorings review-then-commit. Probably with the
exception of the proxy/slotmem plans that were already put forward on the
list.
I would also like to know what more people think about the error message
tag thing? AAUI Rich, Graham, and myself are for including it in 2.4 now,
while Nick prefers to wait. If we decide to wait, it should maybe be
reverted from trunk, too, to make merging of commits to 2.4 easier.
Re: Are we there yet?
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
>
> On Dec 2, 2011, at 6:48 PM, Stefan Fritsch wrote:
>
> > Hi,
> >
> > where are we WRT 2.4?
> >
>
> There seems to be a lot of renewed effort in getting 2.4/trunk is a
> really releasable state, which is all Goodness. Ideally, I'd like
> to release 2.4.0 before the end of the year, but starting off
> 2012 with a new httpd release also makes some sense as well.
>
> With all the changes, I would like to have another 'beta' release
> simply to try to work out any remaining issues, but my fear is
> that this would also encourage a lot of rework rather than
> polishing (if you get my drift). So tagging as a RC puts us in
> the more correct state of mind.
Well I was wondering what the difference is.
I'd still suggest to get a beta out now and then start with
RCs in two week rythm.
Thoughts?
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: Are we there yet?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 2, 2011, at 6:48 PM, Stefan Fritsch wrote:
> Hi,
>
> where are we WRT 2.4?
>
There seems to be a lot of renewed effort in getting 2.4/trunk is a
really releasable state, which is all Goodness. Ideally, I'd like
to release 2.4.0 before the end of the year, but starting off
2012 with a new httpd release also makes some sense as well.
With all the changes, I would like to have another 'beta' release
simply to try to work out any remaining issues, but my fear is
that this would also encourage a lot of rework rather than
polishing (if you get my drift). So tagging as a RC puts us in
the more correct state of mind.
Re: Are we there yet?
Posted by Graham Leggett <mi...@sharp.fm>.
On 03 Dec 2011, at 1:48 AM, Stefan Fritsch wrote:
> where are we WRT 2.4?
>
>
> Blockers:
>
> mod_proxy_scgi.c needs to be fixed for compilation with C89 (easy)
>
>
> The only blocker left in STATUS is this:
>
> * Modules that are not ready for production use must be removed.
> The same for modules without documentation.
The mod_socache_* modules are now all documented.
I also overhauled the caching guide. It previously consisted of a mix of information on HTTP caching and file handle / file content caching, which are two very different things, and the document only made sense if you understood HTTP caching already. The guide is now clearly divided into HTTP caching, socache caching and specialised caching (file handles, etc), and hopefully makes more sense.
Regards,
Graham
--
Re: Are we there yet?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 3, 2011, at 1:30 PM, Graham Leggett wrote:
> On 03 Dec 2011, at 2:49 AM, William A. Rowe Jr. wrote:
>
>> On the subject of logs-relative vs absolute, "/" should prevail, the
>> colon prefix is unacceptable.
>>
>> On the subject of anonymous, "Anonymous mappings are mappings of that area of the process's virtual memory backed by the swap space instead of by a file in the file system name space. In this respect an anonymous mapping is similar to malloc, and is used in some malloc implementations for certain allocations. However, anonymous mappings are not part of the POSIX standard, though implemented by almost all systems."
>> - http://en.wikipedia.org/wiki/Mmap
>>
>> It's pretty obvious why that shm "anonymous" implementation is laughable,
>> as well as unacceptable. But in fact, the <none> implementation appearsto
>> suggest anonymous, already.
>
> To break this down into things to do to fix this, the way I read it is that "anonymous" in this implementation means "put it in a file called anonymous", which is silly for the reasons above.
>
> Would it make sense to make it do this:
>
> * none : no persistent data (anonymous)
> * rel_name : $server_root/rel_name.slotmem
> * /abs_name : $abs_name.slotmem
>
> In other words the relative filename works like everywhere else in the server, and if you happen to use the name "anonymous", you end up with a relative filename, which happens to be the previous behavior.
>
> If so, say the word, I can make it so.
>
+1.
Re: Are we there yet?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 12/3/2011 12:30 PM, Graham Leggett wrote:
> On 03 Dec 2011, at 2:49 AM, William A. Rowe Jr. wrote:
>
>> On the subject of logs-relative vs absolute, "/" should prevail, the
>> colon prefix is unacceptable.
>>
>> On the subject of anonymous, "Anonymous mappings are mappings of that area of the process's virtual memory backed by the swap space instead of by a file in the file system name space. In this respect an anonymous mapping is similar to malloc, and is used in some malloc implementations for certain allocations. However, anonymous mappings are not part of the POSIX standard, though implemented by almost all systems."
>> - http://en.wikipedia.org/wiki/Mmap
>>
>> It's pretty obvious why that shm "anonymous" implementation is laughable,
>> as well as unacceptable. But in fact, the<none> implementation appearsto
>> suggest anonymous, already.
>
> To break this down into things to do to fix this, the way I read it is that "anonymous" in this implementation means "put it in a file called anonymous", which is silly for the reasons above.
>
> Would it make sense to make it do this:
>
> * none : no persistent data (anonymous)
> * rel_name : $server_root/rel_name.slotmem
> * /abs_name : $abs_name.slotmem
>
> In other words the relative filename works like everywhere else in the server, and if you happen to use the name "anonymous", you end up with a relative filename, which happens to be the previous behavior.
>
> If so, say the word, I can make it so.
That sounds sensible (where none triggers apr_shm's anon logic), and
if you have the time, terrific. Do we need the API to be appending
.slotmem for the user? Seems like overkill, nowhere else in httpd
does that happen, AFAICT.
Re: Are we there yet?
Posted by Graham Leggett <mi...@sharp.fm>.
On 03 Dec 2011, at 2:49 AM, William A. Rowe Jr. wrote:
> On the subject of logs-relative vs absolute, "/" should prevail, the
> colon prefix is unacceptable.
>
> On the subject of anonymous, "Anonymous mappings are mappings of that area of the process's virtual memory backed by the swap space instead of by a file in the file system name space. In this respect an anonymous mapping is similar to malloc, and is used in some malloc implementations for certain allocations. However, anonymous mappings are not part of the POSIX standard, though implemented by almost all systems."
> - http://en.wikipedia.org/wiki/Mmap
>
> It's pretty obvious why that shm "anonymous" implementation is laughable,
> as well as unacceptable. But in fact, the <none> implementation appearsto
> suggest anonymous, already.
To break this down into things to do to fix this, the way I read it is that "anonymous" in this implementation means "put it in a file called anonymous", which is silly for the reasons above.
Would it make sense to make it do this:
* none : no persistent data (anonymous)
* rel_name : $server_root/rel_name.slotmem
* /abs_name : $abs_name.slotmem
In other words the relative filename works like everywhere else in the server, and if you happen to use the name "anonymous", you end up with a relative filename, which happens to be the previous behavior.
If so, say the word, I can make it so.
Regards,
Graham
--
Re: Are we there yet?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 12/2/2011 6:10 PM, William A. Rowe Jr. wrote:
> On 12/2/2011 6:08 PM, William A. Rowe Jr. wrote:
>> On 12/2/2011 5:48 PM, Stefan Fritsch wrote:
>>> Hi,
>>>
>>> where are we WRT 2.4?
>>>
>>>
>>> Blockers:
>>>
>>> mod_proxy_scgi.c needs to be fixed for compilation with C89 (easy)
>>>
>>>
>>> The only blocker left in STATUS is this:
>>>
>>> * Modules that are not ready for production use must be removed.
>>> The same for modules without documentation.
>>>
>>> I think we have already removed the obvious candidates WRT maturity.
>>> About documentation, docs/STATUS has this:
>>>
>>> - modules docs
>>> - the follwing modules added since 2.2 lack documentation
>>> - mod_watchdog
>>> - mod_heartbeat
>>> - mod_heartmonitor
>>> - mod_lbmethod_heartbeat
>>> - mod_socache_dbm
>>> - mod_socache_memcache
>>> - mod_socache_shmcb
>>>
>>> Do we want to remove any of these modules?
>>
>> I suspect a single doc for "mod_socache" would probably be appropriate.
>>
>> I was reading http://httpd.apache.org/docs/trunk/mod/mod_slotmem_shm.html
>> and am rather fluxored that the authors apparently don't know the definition
>> of the word "anonymous" shared memory. And there is a brand new syntax if
>> users want log-root-relative paths?
>>
>> Why would slotmem throw away 15 years of filename argument conventions?
On the subject of logs-relative vs absolute, "/" should prevail, the
colon prefix is unacceptable.
On the subject of anonymous, "Anonymous mappings are mappings of that area of the
process's virtual memory backed by the swap space instead of by a file in the file system
name space. In this respect an anonymous mapping is similar to malloc, and is used in some
malloc implementations for certain allocations. However, anonymous mappings are not part
of the POSIX standard, though implemented by almost all systems."
- http://en.wikipedia.org/wiki/Mmap
It's pretty obvious why that shm "anonymous" implementation is laughable,
as well as unacceptable. But in fact, the <none> implementation appearsto
suggest anonymous, already.
Re: Are we there yet?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 12/2/2011 6:08 PM, William A. Rowe Jr. wrote:
> On 12/2/2011 5:48 PM, Stefan Fritsch wrote:
>> Hi,
>>
>> where are we WRT 2.4?
>>
>>
>> Blockers:
>>
>> mod_proxy_scgi.c needs to be fixed for compilation with C89 (easy)
>>
>>
>> The only blocker left in STATUS is this:
>>
>> * Modules that are not ready for production use must be removed.
>> The same for modules without documentation.
>>
>> I think we have already removed the obvious candidates WRT maturity.
>> About documentation, docs/STATUS has this:
>>
>> - modules docs
>> - the follwing modules added since 2.2 lack documentation
>> - mod_watchdog
>> - mod_heartbeat
>> - mod_heartmonitor
>> - mod_lbmethod_heartbeat
>> - mod_socache_dbm
>> - mod_socache_memcache
>> - mod_socache_shmcb
>>
>> Do we want to remove any of these modules?
>
> I suspect a single doc for "mod_socache" would probably be appropriate.
>
> I was reading http://httpd.apache.org/docs/trunk/mod/mod_slotmem_shm.html
> and am rather fluxored that the authors apparently don't know the definition
> of the word "anonymous" shared memory. And there is a brand new syntax if
> users want log-root-relative paths?
>
> Why would slotmem throw away 15 years of filename argument conventions?
>
> IMHO this must be fixed before we call it GA. Whether that happens before
> a 2.4.0 beta doesn't bother me.
[It also is a dev doc. There's nothing here for a user/administrator
to understand why this module exists.]
Re: Are we there yet?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 4, 2011, at 5:29 PM, Graham Leggett wrote:
> On 04 Dec 2011, at 7:38 PM, Jim Jagielski wrote:
>
>> I'm +1 for committing as is and letting people test/patch
>> from there and then backporting ;)
>
> Done in r1210261.
>
> Can you give it a try?
>
Thx. will do!
Re: Are we there yet?
Posted by Graham Leggett <mi...@sharp.fm>.
On 04 Dec 2011, at 7:38 PM, Jim Jagielski wrote:
> I'm +1 for committing as is and letting people test/patch
> from there and then backporting ;)
Done in r1210261.
Can you give it a try?
Regards,
Graham
--
Re: Are we there yet?
Posted by Jim Jagielski <ji...@jaguNET.com>.
I'm +1 for committing as is and letting people test/patch
from there and then backporting ;)
On Dec 4, 2011, at 10:41 AM, Graham Leggett wrote:
> On 04 Dec 2011, at 5:01 PM, Jim Jagielski wrote:
>
>> As you likely know, the origins of slotmem grew out of the httpd-proxy-scoreboard
>> branch (~5.5 years ago) and I assume jfclere had reasons for his choice
>> for how to setup naming of paths, etc... But that is water under the
>> bridge; if we wish to fix that then instead of throwing insults hither and
>> yon, a really good idea would be to make the suggestion that it be
>> fixed based on history/consistency/etc...
>>
>> I see that Graham has suggested a course of action, and I +1'ed
>> it; if Graham lacks the time, I will find some cycles to address
>> and implement.
>
> I currently have this, which compiles but still needs to be tested. Busy this afternoon, so if someone can take a look and see whether this works it would help me. store_filename() seems sane, but the "look up existing segment" stuff needs to be checked that it matches correctly.
>
> Index: modules/slotmem/mod_slotmem_shm.c
> ===================================================================
> --- modules/slotmem/mod_slotmem_shm.c (revision 1210009)
> +++ modules/slotmem/mod_slotmem_shm.c (working copy)
> @@ -119,29 +119,24 @@
> * Persist the slotmem in a file
> * slotmem name and file name.
> * none : no persistent data
> - * anonymous : $server_root/logs/anonymous.slotmem
> - * :rel_name : $server_root/logs/rel_name.slotmem
> - * abs_name : $abs_name.slotmem
> + * rel_name : $server_root/rel_name
> + * /abs_name : $abs_name
> *
> */
> static const char *store_filename(apr_pool_t *pool, const char *slotmemname)
> {
> const char *storename;
> const char *fname;
> - if (strcasecmp(slotmemname, "none") == 0)
> + if (strcasecmp(slotmemname, "none") == 0) {
> return NULL;
> - else if (strcasecmp(slotmemname, "anonymous") == 0)
> - fname = ap_server_root_relative(pool, "logs/anonymous");
> - else if (slotmemname[0] == ':') {
> - const char *tmpname;
> - tmpname = apr_pstrcat(pool, "logs/", &slotmemname[1], NULL);
> - fname = ap_server_root_relative(pool, tmpname);
> }
> + else if (slotmemname[0] != '/') {
> + fname = ap_server_root_relative(pool, slotmemname);
> + }
> else {
> fname = slotmemname;
> }
> - storename = apr_pstrcat(pool, fname, ".slotmem", NULL);
> - return storename;
> + return fname;
> }
>
> static void store_slotmem(ap_slotmem_instance_t *slotmem)
> @@ -269,14 +264,15 @@
> (item_num * sizeof(char)) + basesize;
> apr_status_t rv;
>
> - if (gpool == NULL)
> + if (gpool == NULL) {
> return APR_ENOSHMAVAIL;
> + }
> if (name) {
> - if (name[0] == ':') {
> - fname = name;
> + if (name[0] != '/') {
> + fname = ap_server_root_relative(pool, name);
> }
> else {
> - fname = ap_server_root_relative(pool, name);
> + fname = name;
> }
>
> /* first try to attach to existing slotmem */
> @@ -295,11 +291,11 @@
> }
> }
> else {
> - fname = "anonymous";
> + fname = "none";
> }
>
> /* first try to attach to existing shared memory */
> - fbased = (name && name[0] != ':');
> + fbased = (name != NULL);
> if (fbased) {
> rv = apr_shm_attach(&shm, fname, gpool);
> }
>
> Regards,
> Graham
> --
>
Re: Are we there yet?
Posted by Graham Leggett <mi...@sharp.fm>.
On 04 Dec 2011, at 5:01 PM, Jim Jagielski wrote:
> As you likely know, the origins of slotmem grew out of the httpd-proxy-scoreboard
> branch (~5.5 years ago) and I assume jfclere had reasons for his choice
> for how to setup naming of paths, etc... But that is water under the
> bridge; if we wish to fix that then instead of throwing insults hither and
> yon, a really good idea would be to make the suggestion that it be
> fixed based on history/consistency/etc...
>
> I see that Graham has suggested a course of action, and I +1'ed
> it; if Graham lacks the time, I will find some cycles to address
> and implement.
I currently have this, which compiles but still needs to be tested. Busy this afternoon, so if someone can take a look and see whether this works it would help me. store_filename() seems sane, but the "look up existing segment" stuff needs to be checked that it matches correctly.
Index: modules/slotmem/mod_slotmem_shm.c
===================================================================
--- modules/slotmem/mod_slotmem_shm.c (revision 1210009)
+++ modules/slotmem/mod_slotmem_shm.c (working copy)
@@ -119,29 +119,24 @@
* Persist the slotmem in a file
* slotmem name and file name.
* none : no persistent data
- * anonymous : $server_root/logs/anonymous.slotmem
- * :rel_name : $server_root/logs/rel_name.slotmem
- * abs_name : $abs_name.slotmem
+ * rel_name : $server_root/rel_name
+ * /abs_name : $abs_name
*
*/
static const char *store_filename(apr_pool_t *pool, const char *slotmemname)
{
const char *storename;
const char *fname;
- if (strcasecmp(slotmemname, "none") == 0)
+ if (strcasecmp(slotmemname, "none") == 0) {
return NULL;
- else if (strcasecmp(slotmemname, "anonymous") == 0)
- fname = ap_server_root_relative(pool, "logs/anonymous");
- else if (slotmemname[0] == ':') {
- const char *tmpname;
- tmpname = apr_pstrcat(pool, "logs/", &slotmemname[1], NULL);
- fname = ap_server_root_relative(pool, tmpname);
}
+ else if (slotmemname[0] != '/') {
+ fname = ap_server_root_relative(pool, slotmemname);
+ }
else {
fname = slotmemname;
}
- storename = apr_pstrcat(pool, fname, ".slotmem", NULL);
- return storename;
+ return fname;
}
static void store_slotmem(ap_slotmem_instance_t *slotmem)
@@ -269,14 +264,15 @@
(item_num * sizeof(char)) + basesize;
apr_status_t rv;
- if (gpool == NULL)
+ if (gpool == NULL) {
return APR_ENOSHMAVAIL;
+ }
if (name) {
- if (name[0] == ':') {
- fname = name;
+ if (name[0] != '/') {
+ fname = ap_server_root_relative(pool, name);
}
else {
- fname = ap_server_root_relative(pool, name);
+ fname = name;
}
/* first try to attach to existing slotmem */
@@ -295,11 +291,11 @@
}
}
else {
- fname = "anonymous";
+ fname = "none";
}
/* first try to attach to existing shared memory */
- fbased = (name && name[0] != ':');
+ fbased = (name != NULL);
if (fbased) {
rv = apr_shm_attach(&shm, fname, gpool);
}
Regards,
Graham
--
Re: Are we there yet?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 2, 2011, at 7:08 PM, William A. Rowe Jr. wrote:
> I was reading http://httpd.apache.org/docs/trunk/mod/mod_slotmem_shm.html
> and am rather fluxored that the authors apparently don't know the definition
> of the word "anonymous" shared memory. And there is a brand new syntax if
> users want log-root-relative paths?
>
> Why would slotmem throw away 15 years of filename argument conventions?
>
> IMHO this must be fixed before we call it GA. Whether that happens before
> a 2.4.0 beta doesn't bother me.
As you likely know, the origins of slotmem grew out of the httpd-proxy-scoreboard
branch (~5.5 years ago) and I assume jfclere had reasons for his choice
for how to setup naming of paths, etc... But that is water under the
bridge; if we wish to fix that then instead of throwing insults hither and
yon, a really good idea would be to make the suggestion that it be
fixed based on history/consistency/etc...
I see that Graham has suggested a course of action, and I +1'ed
it; if Graham lacks the time, I will find some cycles to address
and implement.
Re: Are we there yet?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 12/6/2011 8:01 AM, Joe Orton wrote:
> On Fri, Dec 02, 2011 at 06:08:53PM -0600, William Rowe wrote:
>> I suspect a single doc for "mod_socache" would probably be appropriate.
>
> The API docs are in a "single doc", ap_socache.h. They are marked up
> using doxy syntax, if we want that in HTML can't we do that
> automagically using doxygen?
>
> Having to copy and paste that content into docs/ somewhere seems like a
> lot of effort with little benefit, and risks ambiguity and conflict with
> the header description. Which is authoritative?
Not the API docs. The user docs explaining why to load the module,
what it does, and how to configure it.
Re: Are we there yet?
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> On Fri, Dec 02, 2011 at 06:08:53PM -0600, William Rowe wrote:
> > I suspect a single doc for "mod_socache" would probably be
> > appropriate.
>
> The API docs are in a "single doc", ap_socache.h. They are marked up
> using doxy syntax, if we want that in HTML can't we do that
> automagically using doxygen?
We can link to it, it resides here:
http://ci.apache.org/projects/httpd/trunk/doxygen/index.html
> Having to copy and paste that content into docs/ somewhere seems like
> a
> lot of effort with little benefit, and risks ambiguity and conflict
> with
> the header description. Which is authoritative?
>
> Regards, Joe
>
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE
Re: Are we there yet?
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Dec 02, 2011 at 06:08:53PM -0600, William Rowe wrote:
> I suspect a single doc for "mod_socache" would probably be appropriate.
The API docs are in a "single doc", ap_socache.h. They are marked up
using doxy syntax, if we want that in HTML can't we do that
automagically using doxygen?
Having to copy and paste that content into docs/ somewhere seems like a
lot of effort with little benefit, and risks ambiguity and conflict with
the header description. Which is authoritative?
Regards, Joe
Re: Are we there yet?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 12/2/2011 5:48 PM, Stefan Fritsch wrote:
> Hi,
>
> where are we WRT 2.4?
>
>
> Blockers:
>
> mod_proxy_scgi.c needs to be fixed for compilation with C89 (easy)
>
>
> The only blocker left in STATUS is this:
>
> * Modules that are not ready for production use must be removed.
> The same for modules without documentation.
>
> I think we have already removed the obvious candidates WRT maturity.
> About documentation, docs/STATUS has this:
>
> - modules docs
> - the follwing modules added since 2.2 lack documentation
> - mod_watchdog
> - mod_heartbeat
> - mod_heartmonitor
> - mod_lbmethod_heartbeat
> - mod_socache_dbm
> - mod_socache_memcache
> - mod_socache_shmcb
>
> Do we want to remove any of these modules?
I suspect a single doc for "mod_socache" would probably be appropriate.
I was reading http://httpd.apache.org/docs/trunk/mod/mod_slotmem_shm.html
and am rather fluxored that the authors apparently don't know the definition
of the word "anonymous" shared memory. And there is a brand new syntax if
users want log-root-relative paths?
Why would slotmem throw away 15 years of filename argument conventions?
IMHO this must be fixed before we call it GA. Whether that happens before
a 2.4.0 beta doesn't bother me.