Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Errors-To: <wrowe@rowe-clan.net>
Message-ID: <07ef01c12c35$b16aa650$95c0b0d0@roweclan.net>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
To: <dev@httpd.apache.org>
References: <998514781.12703.10.camel@c1619481-a.almda1.sfba.home.com>
 <01082214120501.18802@koj.rkbloom.net>
 <998515720.12703.17.camel@c1619481-a.almda1.sfba.home.com>
 <3B843505.9020503@pacbell.net>
 <998521196.12699.55.camel@c1619481-a.almda1.sfba.home.com>
 <20010822205811.F16727@lyra.org> <3B8496E4.5010801@pacbell.net>
 <20010823003726.R16727@lyra.org>
 <03fd01c12bd2$233cacb0$95c0b0d0@roweclan.net>
 <20010823162107.J26054@lyra.org>
Subject: Re: Letting Table store non-char data
Date: Thu, 23 Aug 2001 19:42:02 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Status: O

From: "Greg Stein" <gstein@lyra.org>
To: <dev@httpd.apache.org>
Sent: Thursday, August 23, 2001 6:21 PM
Subject: Re: Letting Table store non-char data


> On Thu, Aug 23, 2001 at 07:50:03AM -0500, William A. Rowe, Jr. wrote:
> > From: "Greg Stein" <gstein@lyra.org>
> > Sent: Thursday, August 23, 2001 2:37 AM
> > 
> > 
> > > On Wed, Aug 22, 2001 at 10:38:44PM -0700, Brian Pane wrote:
> > > > Greg Stein wrote:
> > > >...
> > > > >Yes there is. apr_pool_userdata_set(..., r->pool)
> > > >...
> > > > Using the "userdata" functions on r->pool as a replacement for a
> > > > hash-based r->notes would be a mistake.  The interface to the userdata
> > > > in a pool is limited to "get" and "set" methods.  The API is missing
> > > > essential operations like "iterate over the set of elements in the userdata"
> > > > and "merge the userdata for a subrequest pool into the parent's r->pool."
> > > 
> > > I would posit those operations are not needed. The notes or userdata are for
> > > specific bits of information. It is not a simple collection that you can
> > > iterate over. In fact, since you can't know the values of each key, you
> > > cannot perform a useful iteration nor do a useful merge.
> > 
> > Precisely.
> > 
> > What negative consequences would that pose for subrequests?
> 
> Um. None... we have zero handling in there for any kind of munging or
> manipulation of r->notes or subreq->notes. It is all simple get/set.

Errr... then cool [I was just noting that when I was walking through the req_rec
structure.]  If someone wants a bit they can iterate, then they can tack on a
note of an apr_table_header_t, but in general, these aren't ment to be iterated.

Either you know what you are dropping in or looking for, or you don't.

+1 to dropping notes then.