Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 1382 invoked by uid 500); 29 Nov 2000 01:45:11 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 1370 invoked from network); 29 Nov 2000 01:45:10 -0000 From: TOKILEY@aol.com Message-ID: <77.cb22c5e.2755b986@aol.com> Date: Tue, 28 Nov 2000 20:44:38 EST Subject: Re: Question about hooks in mod_include. To: new-httpd@apache.org MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Windows AOL sub 86 X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N In a message dated 00-11-28 19:04:30 EST, Greg Stein writes... > Ryan's idea of the hash table registration process is a Good Idea, but let's > export a registration function that people call during their register_hooks > module slot. You actually are going to need both. The case can be argued both ways for one or the other so why not just allow both options and cover all the bases. Having only a 'specific' time when the alternate hooks can be registered ( the hookout issued my mod_include ) might allow the greatest control and the simplest coding but not the most flexibility. Why not make sure a module can actually register/unregister hooks during the actual fixup or handler calls so the module can 'react' to changing circumstances. No big deal. Yours Kevin Kiley CTO, Remote Communications, Inc.