httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: Replacement for mktemp and httpd_monitor
Date Fri, 29 Dec 1995 15:51:07 GMT
Paul Richards wrote:
> 
> In reply to Jim Jagielski who said
> > 
> > Paul Richards wrote:
> > > But, third party tools will have to share code with Apache to ensure
> > > they are using the same heuristic for the creation of the filename. That's
> > > not good because each time that code is changed in Apache all third party
> > > authors have to upgrade their code too.
> > 
> > Feh... That's assuming that the heuristic is:
> > 
> >   1. Hard to code
> >   2. Get's changed alot
> > 
> > #1 definately isn't true (the description is longer than the code) and
> > #2 isn't true either. Why would we change the heuristic?? By provding the
> > exact code that Apache uses, 3rd paryt apps are _assured_ OS independence.
> 
> No. That's assuming that instead of a fixed string there is a piece of
> code generating these names. No matter how simple that piece of may be
> the piece of code first has to be obtained from the Apache group before
> a third party author can write code.

Huh....? The docs can simply say: "Here is the code that defines the name
of the scoreboard file" and then lists the 2 or 3 lines. If the scoreboard
name _must_ be dynamic, then we simply must define how it's defined.
No-one needs to get the code or anything other than the docs from Apache.

> 
> Yes, I did look at the diffs, in some detail. It's nothing at all like my
> two lines (one to get the pid and one to print out a string). It's exactly
> what it purports to be, a new, OS portable version of mktemp and I still
> think it's unecessary and is only an issue because the original code
> mistakenly used mktemp. These are not anonymous temporary files!

Agreed. So we change the name maybe to 'apache-name' or 'mkname' or
something like that.
> > 
> > The scoreboard name isn't in the config files at all. It's hardcoded into
> > apache.
> 
> Yes, but I think it should be a config option.

That is a good idea, but it makes things difficult for the 3rd party
apps since they need to find the config file and then scan it for the
location of the scoreboard and then, if it doesn't exist, use the default
location. No matter what, having scoreboard in /tmp isn't a good idea
and we never do that here.

> 
> > Hello! The function doesn't have to be copied anywhere. It was "created"
> > as a function to make things easier to understand and more modular. We
> 
> It does, it has to be copied into third party apps. The whole point was to
> make it possible to develop third party apps independantly of Apache.

The 3rd party apps simply need to know how to generate the name. If you
want to consider this as "copying" the function, then that's OK. But recall
that to _use_ the scoreboard they also need to "copy" the internal
structure of it as well. If we can define the structure in the docs, we
can also define the name as well.

> But you're solving the wrong problem.
> 
> > call... Now where exactly is the major problem with the implementation?
> 
> The problem is that third party apps now have to include part of
> the Apache src tree in order to read the scoreboard file.
> 
> Let's get back to the original problem, httpd_monitor wasn't portable
> because it assumed a "standard" format for the scoreboard file when
> in fact it wasn't because it used mktemp and mktemp isn't portable.
> Now, how exactly does your patch help httpd_monitor, remember, it's a perl
> script so you can't just drop in your function? Giving me the function
> direct from the Apache sources isn't going to help my sh script or my
> tcl/tk tool?

My patch provides for a C version of httpd_monitor. Perl is no longer
used, for just the reason we are discussing... It's hard to implement
OS independent perl scripts that work on C structures. Although it's
a Good Idea to have to avoid including the Apache src tree, httpd_monitor
is included in the support tree, so why not? If we consider 3rd party
apps as those that are completely and totally seperate from the Apache
code, then that makes things different and difficult... The only way to
do things correctly would be to have httpd itself report the location
and name of the scoreboard file. Having it in the config-file helps
a great deal, but it still doesn't involve the problem in the dynamic
naming of the scoreboard (i.e. how do we get the PID, etc...). Not only
that, but, of course, we still need to know where the PID file is kept,
etc....

All this could be avoided by having httpd report the fullpathname of the
scoreboard file. Of course, that would mean that it would need to be
runnable by anyone.

Oh well... let's step back a few steps. The new httpd_monitor requires
that there is an OS-independent way of generating filenames. The patches
do that and with minimal impact on Apache itself. It's a minor patch
to Apache to accomodate a useful tool. As other useful tools are generated,
maybe Apache should do things different, but at least with the patches,
useful tools can be built _now_ with only 1 item being "unknown" (the
location of the PIDfile), which must be defined by a run-time option
if the hardwired-default isn't correct. All else is obtained at no charge
to httpd_monitor and no guesswork on the person compiling/running/using
the tool.

Before we reinvent the wheel, shouldn't we see if just straightening this
particular spoke gives us the milage we want?

-- 
Jim Jagielski  << jim@jaguNET.com >>   |           "Wind the frog!"
  **  jaguNET Access Services  **      |       - Woody (from Toy Story)
++       Email: info@jaguNET.com      +++        Voice:  410-931-3157       ++
++       http://www.jaguNET.com/      +++         Data: 410-931-7060        ++

Mime
View raw message