Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
To: "Issac Goldstand" <margol@beamartyr.net>
Cc: "Stas Bekman" <stas@stason.org>,
   "apreq dev list" <apreq-dev@httpd.apache.org>
Subject: Re: [rfc] a few milestones (was Re: Updating the Website?)
References: <m33ck6zg3t.fsf@sol.sunstarsys.com>
	<m3vfx0y05j.fsf@sol.sunstarsys.com> <3EAB6E12.1000109@stason.org>
	<m3ptn8xy63.fsf@sol.sunstarsys.com> <3EAB8657.3040403@stason.org>
	<m3llxwxbqb.fsf@sol.sunstarsys.com> <3EAC652E.5060405@stason.org>
	<00c001c30d5b$29fe1bd0$0100a8c0@fmenc001dev>
From: Joe Schaefer <joe@sunstarsys.com>
Date: 28 Apr 2003 09:03:08 -0400
In-Reply-To: <00c001c30d5b$29fe1bd0$0100a8c0@fmenc001dev>
Message-ID: <m3d6j6ydtf.fsf@sol.sunstarsys.com>
Lines: 34
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

"Issac Goldstand" <margol@beamartyr.net> writes:

> My $0.02:
>   I think we're making too many new root namespaces for modperl2:
> Apache2::  APR:: ModPerl:: etc
> I think that we should start taking one of those as a "roof" as to 
> not create too much confusing clutter; after all, ALL of these
> namespaces are logically connected because they ALL require mod_perl2, 

Fair enough, but there's lots of new things in libapreq that
we should clarify:

  1) libapreq-2 no longer requires httpd to operate;  it can be
     used in other environments (like CGI) now.  IMO it would
     be nice if CGI scripts that use our Perl API (whatever
     it turns out to be) will also work cleanly as Apache::Registry 
     scripts.

  2) libapreq-2 is meant to be safe to use just about anywhere 
     within the server: hooks, filters, handlers, etc.  The 
     downside is that it's no longer possible for libapreq to 
     automatically do the POST parsing (we've relinquished
     control of that to the content-handler itself).

> Plus, think about third-party developers.  They're gonna go bananas
> trying to figure out which of these new namespaces to start developing
> for.  So I'm against making either an Apreq:: or an APREQ:: suite. 

What concerns me most about Apache::Request is backwards-compatibility.
If people prefer to document the changes to Apache::Request instead
of introducing a new namespace, that's fine with me also.

-- 
Joe Schaefer