Return-Path: Delivered-To: apmail-httpd-test-dev-archive@httpd.apache.org Received: (qmail 80477 invoked by uid 500); 5 Sep 2002 14:25:09 -0000 Mailing-List: contact test-dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: test-dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list test-dev@httpd.apache.org Received: (qmail 80464 invoked from network); 5 Sep 2002 14:25:08 -0000 Date: Thu, 5 Sep 2002 17:22:15 +0200 From: Jacek Prucia To: test-dev@httpd.apache.org Subject: Re: where to start? Message-Id: <20020905172215.41377997.jacek.prucia@7bulls.com> In-Reply-To: <20020904173818.GV16785@apache.org> References: <20020904140115.0d47bca8.jacek.prucia@7bulls.com> <20020904173818.GV16785@apache.org> Organization: 7bulls.com S.A. X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Wed, 4 Sep 2002 10:38:18 -0700 Justin Erenkrantz 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/