apachectl/httpd compromise?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 12:31 PM 5/27/2002, you wrote:

>On Mon, 27 May 2002, Sascha Schumann wrote:
>
> > > -0.9.  Whoever said we were deprecating them?  I thought the plan was 
> that
> > > apachectl would continue to accept 'start|stop|restart' and would pass
> > > them as 'httpd -k $ARGV' to Apache.  That is what apachectl does
> > > currently.  Yes, you *could* say apachectl -k start with the new code and
> > > it would work (I see no problem with that), but where in there are we
> > > deprecating the old way?  It sounds like just a convenience that -k 
> works,
> > > not that it's the new preferred method.  Getting rid of 'apachectl start'
> > > and friends seems pointless to me, and it will irritate countless admins
> > > to change it after so many years for no reason.
>
>Part of the point of the refactoring of apachectl was to get rid of two
>major problems:
>
>- Having two different sets of arguments for httpd and apachectl is
>confusing and difficult to document

How so?  How is this different from syntax differences between any
other two commands?  Here is a wrapper used by administrators for
five years, and you want to change the syntax "just because"?

>So yes, -k should be the new preferred method.

Preferred for apacectl?  This change seems entirely gratuitous.

I have an entirely different approach we might want to consider.  Rather
than implement -k, deprecate the -k flag in Win32.  Apache takes no
arguments today, only options.  Introducing a single argument doesn't
seem like a bad compromise.

So we review the Win32 code and accept either -k start or simply start.
And in the Unix port, we introduce httpd start [no -k flag whatsoever.]
Phase out the -k documentation for Win32 in favor of the simple verb.

If we wanted to allow httpd to stop itself by absolute PID, we could allow
a second argument, the daemon's ID [be it a PID on unix, or a service's
name on Win32.]

So simply,

httpd start
httpd stop

or more explicitly,

httpd stop 2914

or where 'named daemons' are supported,
[e.g. Win32, perhaps OSX at some point]

httpd stop Apache2

Thoughts?

Bill

Re: apachectl/httpd compromise?

[Marc Slemko <ma...@znep.com>]

On Mon, 27 May 2002, Joshua Slive wrote:

> 
> On Mon, 27 May 2002, William A. Rowe, Jr. wrote:
> > >- Having two different sets of arguments for httpd and apachectl is
> > >confusing and difficult to document
> >
> > How so?  How is this different from syntax differences between any
> > other two commands?  Here is a wrapper used by administrators for
> > five years, and you want to change the syntax "just because"?
> 
> Because any time someone tells you to use command line option "-xxx" (to
> activate apache's porno mode, perhaps), you need to figure out where the
> heck it goes and how to get it there.  I'm not saying it's the end of the
> world, I'm saying it's added complexity that we should remove if we can.

There should be a wrapper script that starts Apache in the proper
mode for "normally" running a given instance on a given system.

If they want to always have the porno mode enabled, then it should 
be added to the configuration of that script, not specified on the 
command line as an argument to that script.

If they want to start with porno mode just for some special testing, 
then they need to be able to pass that command line option to httpd
somehow; in the past, this would just be by running it manually with
all the options.  Since we now require other random stuff to be done
before running httpd, we either need a script that does that or we need
a way for the wrapper script to pass httpd options through.

The wrapper script, however, is not normally designed to be used 
in a mode where a bunch of command line options are passed to it 
every time it is run.  

> The fact that apachectl's arguments are standard for init scripts was
> something I had forgotten about.

It isn't just that its arguments are standard for init scripts, it 
_IS_ an init script.

I am wary of trying to overload it to be both an init script and
a magic-httpd-wrapper-that-takes-any-argument script.  Some complexity
comes from having two different things that can be run, the init
script and the program itself directly.  But I think even more
complexity comes from having one thing that magically plays both
roles, especially if it is not designed very carefully to play both
roles.

> 
> > I have an entirely different approach we might want to consider.  Rather
> > than implement -k, deprecate the -k flag in Win32.  Apache takes no
> > arguments today, only options.  Introducing a single argument doesn't
> > seem like a bad compromise.
> 
> That was my favorite option from the beginning.  But I'm not sure how easy
> it would be to implement with the currect getargs code.

I've never been a big fan of programs that take some arguments as 
magic words on the command line, some as options, etc.  There are 
various standards for command line usage, and I don't know that having
command lines like "httpd start" fits into any of them.  How is this 
different than an init script taking a "start" option?  Mostly a 
matter of convention; init scripts are a well understood and widely 
used concept, and generally only have the one argument passed to them
without a bunch of other command line options.

Re: apachectl/httpd compromise?

[Joshua Slive <jo...@slive.ca>]

On Mon, 27 May 2002, William A. Rowe, Jr. wrote:
> >- Having two different sets of arguments for httpd and apachectl is
> >confusing and difficult to document
>
> How so?  How is this different from syntax differences between any
> other two commands?  Here is a wrapper used by administrators for
> five years, and you want to change the syntax "just because"?

Because any time someone tells you to use command line option "-xxx" (to
activate apache's porno mode, perhaps), you need to figure out where the
heck it goes and how to get it there.  I'm not saying it's the end of the
world, I'm saying it's added complexity that we should remove if we can.

The fact that apachectl's arguments are standard for init scripts was
something I had forgotten about.

> I have an entirely different approach we might want to consider.  Rather
> than implement -k, deprecate the -k flag in Win32.  Apache takes no
> arguments today, only options.  Introducing a single argument doesn't
> seem like a bad compromise.

That was my favorite option from the beginning.  But I'm not sure how easy
it would be to implement with the currect getargs code.

Joshua.