Greg Stein wrote:
>On Wed, Aug 22, 2001 at 03:59:56PM -0700, Ian Holsman wrote:
>
>>On Wed, 2001-08-22 at 15:41, Brian Pane wrote:
>>
>>>Ian Holsman wrote:
>>>
>>>>On Wed, 2001-08-22 at 14:12, Ryan Bloom wrote:
>>>>
>>>>>We had binary tables, but we removed them, because that is what hash
>>>>>tables are for.
>>>>>
>>>>agreed.
>>>>but there are no hash tables on the request rec structure.
>>>>
>
>Yes there is. apr_pool_userdata_set(..., r->pool)
>
>>>>My problem is that I have a module which implements a custom SSI tag and
>>>>a 'postfix' hook.
>>>>the postfix hook sets up the key based on the incoming request.
>>>>
>
>apr_pool_userdata_set("ian-ssi-tag-data", data, apr_pool_cleanup_null,
> r->pool);
>
>>>>when the SSI tag gets called (~10-50 per page) it needs to get the key
>>>>the postfix hook had set up.
>>>>
>
>apr_pool_userdata_get(&data, "ian-ssi-tag-data", r->pool);
>
>>...
>>
>>>How about changing request_rec->notes to a hash table? This would be
>>>a relatively simple change, as the notes field isn't used in a huge
>>>number of places in the standard modules.
>>>
>
>No need. IMO, r->notes should just go away. It is pointless nowadays.
>
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."
--Brian
