You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ryan Bloom <rb...@covalent.net> on 2001/08/22 23:12:05 UTC
Re: Letting Table store non-char data
We had binary tables, but we removed them, because that is what hash
tables are for.
Ryan
On Wednesday 22 August 2001 14:13, Ian Holsman wrote:
> i was wondering if there is any reason why table's can store other
> data types (like integers).
--
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: Letting Table store non-char data
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 22 August 2001 20:58, 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.
++1
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: Letting Table store non-char data
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Greg Stein" <gs...@lyra.org>
To: <de...@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" <gs...@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.
Re: Letting Table store non-char data
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Aug 23, 2001 at 07:50:03AM -0500, William A. Rowe, Jr. wrote:
> From: "Greg Stein" <gs...@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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Letting Table store non-char data
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Greg Stein" <gs...@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?
Re: Letting Table store non-char data
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Aug 23, 2001 at 01:22:00AM -0700, Brian Pane wrote:
> Greg Stein wrote:
> >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.
Yup. You could store an app-specific hash table in the userdata, and assign
specific semantics to the use of that structure (including things like
arbitrary scanning of its contents). That would allow for the operations
you're thinking of.
But just iterating over the userdata in a pool could be a problem. Heck...
the key might not even be a valid pointer :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Letting Table store non-char data
Posted by Brian Pane <bp...@pacbell.net>.
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
Re: Letting Table store non-char data
Posted by Greg Stein <gs...@lyra.org>.
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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Letting Table store non-char data
Posted by Brian Pane <bp...@pacbell.net>.
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
Re: Letting Table store non-char data
Posted by Ryan Bloom <rb...@covalent.net>.
On Thursday 23 August 2001 07:45, Eric Prud'hommeaux wrote:
> On Wed, Aug 22, 2001 at 09:03:21PM -0700, Ian Holsman wrote:
> > On Wed, 2001-08-22 at 20:58, 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)
> >
> > Thanks.
> > never knew about this function.
>
> I am switching my code to use pool userdata but wonder if swapping the
> parms make make the calling convention more consistent with the other
> pool methods that take the pool as first parm.
>
> - apr_status_t apr_pool_userdata_get(void **, char *, apr_pool_t *);
> + apr_status_t apr_pool_userdata_get(apr_pool_t *, char *, void **);
> # this ptr attr value
All of the APR functions take the pool as the last var. This was due to a
communication gaffe when I first wrote APR, but it would be VERY painful
to change it now.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: Letting Table store non-char data
Posted by Eric Prud'hommeaux <er...@w3.org>.
On Wed, Aug 22, 2001 at 09:03:21PM -0700, Ian Holsman wrote:
> On Wed, 2001-08-22 at 20:58, 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)
> Thanks.
> never knew about this function.
I am switching my code to use pool userdata but wonder if swapping the
parms make make the calling convention more consistent with the other
pool methods that take the pool as first parm.
- apr_status_t apr_pool_userdata_get(void **, char *, apr_pool_t *);
+ apr_status_t apr_pool_userdata_get(apr_pool_t *, char *, void **);
# this ptr attr value
--
-eric
(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.
Re: Letting Table store non-char data
Posted by Ian Holsman <Ia...@cnet.com>.
On Wed, 2001-08-22 at 20:58, 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)
Thanks.
never knew about this function.
>
> > > >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.
>
> Cheers,
> -g
>
--
Ian Holsman
Performance Measurement & Analysis
CNET Networks - 415 364-8608
Re: Letting Table store non-char data
Posted by Greg Stein <gs...@lyra.org>.
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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Letting Table store non-char data
Posted by Ian Holsman <Ia...@cnet.com>.
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.
> >
> >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.
> >
> >when the SSI tag gets called (~10-50 per page) it needs to get the key
> >the postfix hook had set up.
> >
> >another module we have does a lot of work in the SSI call and needs to
> >cache the data for subsequent calls to itself.
> >
> 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.
>
> --Brian
>
that would work for me.
I could submit a patch tonight to do this.
>
--
Ian Holsman
Performance Measurement & Analysis
CNET Networks - 415 364-8608
Re: Letting Table store non-char data
Posted by Brian Pane <bp...@pacbell.net>.
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.
>
>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.
>
>when the SSI tag gets called (~10-50 per page) it needs to get the key
>the postfix hook had set up.
>
>another module we have does a lot of work in the SSI call and needs to
>cache the data for subsequent calls to itself.
>
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.
--Brian
Re: Letting Table store non-char data
Posted by Ian Holsman <Ia...@cnet.com>.
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.
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.
when the SSI tag gets called (~10-50 per page) it needs to get the key
the postfix hook had set up.
another module we have does a lot of work in the SSI call and needs to
cache the data for subsequent calls to itself.
..Ian
> Ryan
>
> On Wednesday 22 August 2001 14:13, Ian Holsman wrote:
> > i was wondering if there is any reason why table's can store other
> > data types (like integers).
>
--
Ian Holsman
Performance Measurement & Analysis
CNET Networks - 415 364-8608