httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacek Prucia <jacek.pru...@7bulls.com>
Subject Re: where to start?
Date Thu, 05 Sep 2002 15:22:15 GMT
On Wed, 4 Sep 2002 10:38:18 -0700
Justin Erenkrantz <jerenkrantz@apache.org> wrote:

[...]
> > [...] What if there's no command line
> > options, but only plain config file? I think we schould do as
> > listed:
> 
> Yeah, APR should have all of the getopt bits already available.
> But, I would definitely prefer that we not overdo command-line
> options.  (The one killer command line argument would be
> --no-delay - which shuts off the delays.)

Hmmm... sounds good, and we could toss all command line options and
leave only those two:

-h/--help       - quick help page (man flood(1), location of $DOCDIR,
etc.)
-v/--version    - FLOOD_VERSION + farmer creation model (thread, fork)

Since flood is supposed to be hidden behind few nice GUI's, we could
also toss --no-delay. It would be trival to have that functionality in
GUI frontend.

> > 1. check for first megaconglomerate, step 2 if not found
> > 2. check for first collective, step 3 if not found
> > 3. check for first farm, step 4 if not found
> > 4. check for first farmer, step 5 if not found
> > 5. bail out
> 
> I'm not 100% sure we can go to step 4.  Would we just say that it
> is one farmer?

Yep. I was even thinking about ability to run single URL out of context
of whole config file. Suppose you have this big-ass config with lotsa
URL's, and one of them (preferably at the end of config) barfs out with
regexp failure. How would you debug it? Waiting for all preceding URLs
to complete? That would be a nightmare. So, I was thinking about ability
to run *any* desired object (url, farmer) with chain of parent objects
(up to at least farm) generated in realtime, just for purpose of this
one run.

I was thinking about command line options (-f, -r, -u), but since we're
talking GUI, I'll just move that issue down my TODO list. It makes much
more sense to deal with that when we have some frontend ready.

[...]
> Well, el-kabong is kind of political limbo, so I wouldn't wait for
> it to get checked-in.  If you do want to use it and are willing to
> code up patches for it, we may be able to use that as a stick to
> find el-kabong a home (and you'd need to acquire the source to it
> too).

Hmmm... well, I'm pretty active recently, because I got some spare time.
This however is sure to change in a few days. So I'll be happy to help,
but el-kabong needs full-time maintainer. Apart from that I think flood
would benefit from such library under ASF umbrella.

[...]
> serf is probably a while off.  There's something in its repository,
> but we still haven't finished out its design yet.  There's a lot more
> that we need to think about.  But, feel free to jump into the
> discussions over on serf-dev@ if you like.

Yeah. I'll be probably just lurking (like on dev@httpd) because of that
time problem ;|

regards,
-- 
Jacek Prucia
7bulls.com S.A.
http://www.7bulls.com/



Mime
View raw message