Greg Stein wrote:
>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.
>
Hmmm...I think I agree. I do have some cases in which the ability to
iterate over the notes table is essential for sharing extensible sets
of data among modules, but they depend on naming conventions for the
elements in the table (so that the collaborating modules know what elements
are relevant and can interpret the values meaningfully). But it's a
lot cleaner to store this data in an appliation-specific data structure
that in turn is stored as a userdata element in the pool.
--Brian
