You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Ryan Bloom <rb...@covalent.net> on 2001/09/19 17:19:01 UTC
Release time?
I would like to move APR to a releasable state finally. To do this, we need to
finish the locking API at the very least. Does anybody have other issues that
need to be resolved?
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: apr_table_t (was: Re: Release time?)
Posted by Brian Pane <bp...@pacbell.net>.
William A. Rowe, Jr. wrote:
[...]
>In the case of tables, the minimum api I would accept includes a duplicate
>and truncate function. Also (of course) the existing add, as well as an
>insert (since we loose the ability to do so with this change.)
>
Insert? For a table, insert==add, because it's an unordered collection.
Similarly, the semantics of truncate would be unpredictable.
>In the case of hashes, we still need an efficient duplicate.
>
I agree.
--Brian
Re: apr_table_t (was: Re: Release time?)
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
From: "Justin Erenkrantz" <je...@ebuilt.com>
Sent: Wednesday, September 19, 2001 4:38 PM
> On Wed, Sep 19, 2001 at 02:33:22PM -0700, Ryan Bloom wrote:
> > Which philosophy would that be?
> >
> > Tables have worked this way for a very long time. Take a look at the docs
> > in apr_table.h:
> >
> > /* This has to be first to promote backwards compatibility with
> > * older modules which cast a apr_table_t * to an apr_array_header_t *...
> > * they should use the table_elts() function for most of the
> > * cases they do this for.
> > */
> > /** The underlying array for the table */
> > apr_array_header_t a;
>
> No reason not to change it now.
>
> We're explicitly not promoting backwards compatibility with any older
> modules with httpd-2.0. -- justin
In the case of tables, the minimum api I would accept includes a duplicate
and truncate function. Also (of course) the existing add, as well as an
insert (since we loose the ability to do so with this change.)
In the case of hashes, we still need an efficient duplicate.
Bill
Re: apr_table_t (was: Re: Release time?)
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Sep 19, 2001 at 02:33:22PM -0700, Ryan Bloom wrote:
> Which philosophy would that be?
>
> Tables have worked this way for a very long time. Take a look at the docs
> in apr_table.h:
>
> /* This has to be first to promote backwards compatibility with
> * older modules which cast a apr_table_t * to an apr_array_header_t *...
> * they should use the table_elts() function for most of the
> * cases they do this for.
> */
> /** The underlying array for the table */
> apr_array_header_t a;
No reason not to change it now.
We're explicitly not promoting backwards compatibility with any older
modules with httpd-2.0. -- justin
Re: apr_table_t (was: Re: Release time?)
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 19 September 2001 02:28 pm, Justin Erenkrantz wrote:
> On Wed, Sep 19, 2001 at 12:25:36PM -0700, Brian Pane wrote:
> > The original approach that I posted was a traditional iterator object:
> >
> > typedef struct apr_table_iter_t apr_table_iter_t;
> > apr_table_iter_t * apr_table_iter_make(apr_pool_t *p,
> > const apr_table_t *t);
> >
> > apr_status_t apr_table_iter_next(apr_table_iter_t *iterator,
> > const char **key,
> > const char **value);
> >
> > In my experience, this is an easy change to make, at least in the core
> > modules (I only had to change half a dozen places in httpd-2.0 to get
> > it to work.)
> >
> > Does anybody have thoughts for or against this iterator API?
>
> +1. Accessing the structures directly goes against our philosophy.
Which philosophy would that be?
Tables have worked this way for a very long time. Take a look at the docs
in apr_table.h:
/* This has to be first to promote backwards compatibility with
* older modules which cast a apr_table_t * to an apr_array_header_t *...
* they should use the table_elts() function for most of the
* cases they do this for.
*/
/** The underlying array for the table */
apr_array_header_t a;
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: apr_table_t (was: Re: Release time?)
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 19, 2001 at 09:55:56PM -0700, Justin Erenkrantz wrote:
> On Wed, Sep 19, 2001 at 09:48:30PM -0700, Brian Pane wrote:
> > Following the pattern of the apr_hash_t iterator is fine with me, too.
> >
> > But I just noticed a small problem with the apr_hash_t iterator:
> >
> > APR_DECLARE(void) apr_hash_this(apr_hash_index_t *hi, const void **key,
> > apr_ssize_t *klen, void **val);
> >
> > The "val" is non-const. Thus an app iterating through a hash table
> > can overwrite a value with NULL. That's probably bad, as it violates
> > what otherwise is an invariant about apr_hash_t: values in it cannot
> > be NULL. If you pass a NULL value to apr_hash_set(), it deletes the
> > key from the hash table, so it's ordinarily impossible to have a NULL
> > value in a hash table.
> >
> > I propose that we fix this by either:
> > * changing the hash iterator to a const iterator, or
> > * documenting it.
>
> I think documenting it.
>
> I thought we wanted it this way so that you could modify the value
> in the hash table without calling set or discarding the const.
> If they set it to NULL, that's their problem.
I think both of you need to go back and look at that again.
void *val;
apr_hash_this(hi, NULL, NULL, &val);
How does that allow me to change the value in the hash table? Answer: it
doesn't. Of course, you can change whatever it points to, but you cannot
change the actual pointer-value.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: apr_table_t (was: Re: Release time?)
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Sep 19, 2001 at 09:48:30PM -0700, Brian Pane wrote:
> Following the pattern of the apr_hash_t iterator is fine with me, too.
>
> But I just noticed a small problem with the apr_hash_t iterator:
>
> APR_DECLARE(void) apr_hash_this(apr_hash_index_t *hi, const void **key,
> apr_ssize_t *klen, void **val);
>
> The "val" is non-const. Thus an app iterating through a hash table
> can overwrite a value with NULL. That's probably bad, as it violates
> what otherwise is an invariant about apr_hash_t: values in it cannot
> be NULL. If you pass a NULL value to apr_hash_set(), it deletes the
> key from the hash table, so it's ordinarily impossible to have a NULL
> value in a hash table.
>
> I propose that we fix this by either:
> * changing the hash iterator to a const iterator, or
> * documenting it.
I think documenting it.
I thought we wanted it this way so that you could modify the value
in the hash table without calling set or discarding the const.
If they set it to NULL, that's their problem.
My $.02. -- justin
Re: apr_table_t (was: Re: Release time?)
Posted by Brian Pane <bp...@pacbell.net>.
Ian Holsman wrote:
>On Wed, 2001-09-19 at 14:28, Justin Erenkrantz wrote:
>
>>On Wed, Sep 19, 2001 at 12:25:36PM -0700, Brian Pane wrote:
>>
>>>The original approach that I posted was a traditional iterator object:
>>>
>>> typedef struct apr_table_iter_t apr_table_iter_t;
>>> apr_table_iter_t * apr_table_iter_make(apr_pool_t *p,
>>> const apr_table_t *t);
>>>
>>> apr_status_t apr_table_iter_next(apr_table_iter_t *iterator,
>>> const char **key,
>>> const char **value);
>>>
>>>In my experience, this is an easy change to make, at least in the core
>>>modules (I only had to change half a dozen places in httpd-2.0 to get
>>>it to work.)
>>>
>>>Does anybody have thoughts for or against this iterator API?
>>>
>>+1. Accessing the structures directly goes against our philosophy.
>>
>
>Can we use the same API structure as the hash table?
>
> apr_table_index_t* apr_table_first( apr_pool_t*p, apr_table_t*t)
> apr_table_index_t* apr_table_next(apr_table_index_t*)
> void apr_table_this(apr_table_index_t*,const char**key,const
> char**value)
>
Following the pattern of the apr_hash_t iterator is fine with me, too.
But I just noticed a small problem with the apr_hash_t iterator:
APR_DECLARE(void) apr_hash_this(apr_hash_index_t *hi, const void **key,
apr_ssize_t *klen, void **val);
The "val" is non-const. Thus an app iterating through a hash table
can overwrite a value with NULL. That's probably bad, as it violates
what otherwise is an invariant about apr_hash_t: values in it cannot
be NULL. If you pass a NULL value to apr_hash_set(), it deletes the
key from the hash table, so it's ordinarily impossible to have a NULL
value in a hash table.
I propose that we fix this by either:
* changing the hash iterator to a const iterator, or
* documenting it.
--Brian
Re: apr_table_t (was: Re: Release time?)
Posted by Ian Holsman <ia...@cnet.com>.
On Wed, 2001-09-19 at 14:28, Justin Erenkrantz wrote:
> On Wed, Sep 19, 2001 at 12:25:36PM -0700, Brian Pane wrote:
> > The original approach that I posted was a traditional iterator object:
> >
> > typedef struct apr_table_iter_t apr_table_iter_t;
> > apr_table_iter_t * apr_table_iter_make(apr_pool_t *p,
> > const apr_table_t *t);
> >
> > apr_status_t apr_table_iter_next(apr_table_iter_t *iterator,
> > const char **key,
> > const char **value);
> >
> > In my experience, this is an easy change to make, at least in the core
> > modules (I only had to change half a dozen places in httpd-2.0 to get
> > it to work.)
> >
> > Does anybody have thoughts for or against this iterator API?
>
> +1. Accessing the structures directly goes against our philosophy.
Can we use the same API structure as the hash table?
apr_table_index_t* apr_table_first( apr_pool_t*p, apr_table_t*t)
apr_table_index_t* apr_table_next(apr_table_index_t*)
void apr_table_this(apr_table_index_t*,const char**key,const
char**value)
http://docx.webperf.org/group__APR__Hash.html
> -- justin
--
Ian Holsman IanH@cnet.com
Performance Measurement & Analysis
CNET Networks - (415) 364-8608
Re: apr_table_t (was: Re: Release time?)
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Sep 19, 2001 at 12:25:36PM -0700, Brian Pane wrote:
> The original approach that I posted was a traditional iterator object:
>
> typedef struct apr_table_iter_t apr_table_iter_t;
> apr_table_iter_t * apr_table_iter_make(apr_pool_t *p,
> const apr_table_t *t);
>
> apr_status_t apr_table_iter_next(apr_table_iter_t *iterator,
> const char **key,
> const char **value);
>
> In my experience, this is an easy change to make, at least in the core
> modules (I only had to change half a dozen places in httpd-2.0 to get
> it to work.)
>
> Does anybody have thoughts for or against this iterator API?
+1. Accessing the structures directly goes against our philosophy.
-- justin
Re: apr_table_t (was: Re: Release time?)
Posted by Brian Pane <bp...@pacbell.net>.
Greg Stein wrote:
>On Wed, Sep 19, 2001 at 11:07:37AM -0700, Brian Pane wrote:
>
>>...
>>If not, I still would like to replace apr_table_elts with a different
>>interface that doesn't make any promises about apr_table_t being
>>an apr_array_header_t. That will enable us to fix the performance
>>in later releases without breaking people's application code.
>>
>
>First change is to introduce new APIs to do whatever people were referencing
>->nelts or ->elts for. Convert all code to use that, so that the apr_table_t
>structure can be opaque.
>
>Once that is done, then we can change the implementation at will, at any
>time. And the new APIs must exist anyways.
>
>So... I'd suggest working on the APIs first, and getting code to use them.
>*Then* we can look at revamping the table implementation.
>
The original approach that I posted was a traditional iterator object:
typedef struct apr_table_iter_t apr_table_iter_t;
apr_table_iter_t * apr_table_iter_make(apr_pool_t *p,
const apr_table_t *t);
apr_status_t apr_table_iter_next(apr_table_iter_t *iterator,
const char **key,
const char **value);
In my experience, this is an easy change to make, at least in the core
modules (I only had to change half a dozen places in httpd-2.0 to get
it to work.)
Does anybody have thoughts for or against this iterator API?
Thanks,
--Brian
apr_table_t (was: Re: Release time?)
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 19, 2001 at 11:07:37AM -0700, Brian Pane wrote:
>...
> If not, I still would like to replace apr_table_elts with a different
> interface that doesn't make any promises about apr_table_t being
> an apr_array_header_t. That will enable us to fix the performance
> in later releases without breaking people's application code.
First change is to introduce new APIs to do whatever people were referencing
->nelts or ->elts for. Convert all code to use that, so that the apr_table_t
structure can be opaque.
Once that is done, then we can change the implementation at will, at any
time. And the new APIs must exist anyways.
So... I'd suggest working on the APIs first, and getting code to use them.
*Then* we can look at revamping the table implementation.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Release time?
Posted by Brian Pane <bp...@pacbell.net>.
Ryan Bloom wrote:
>I would like to move APR to a releasable state finally. To do this, we need to
>finish the locking API at the very least. Does anybody have other issues that
>need to be resolved?
>
I have just one issue: apr_table_t
As of a couple of weeks ago, we were debating whether or not to
replace its internals with a faster data structure. If we do want
to make a change like this, now is a good time.
If not, I still would like to replace apr_table_elts with a different
interface that doesn't make any promises about apr_table_t being
an apr_array_header_t. That will enable us to fix the performance
in later releases without breaking people's application code.
--Brian
Re: Release time?
Posted by Ian Holsman <ia...@cnet.com>.
On Wed, 2001-09-19 at 10:19, Cliff Woolley wrote:
> On 19 Sep 2001, Ian Holsman wrote:
>
> > > APR-util can be released on a different schedule from APR, but yes
> > > we should move APR-util to release, and all of these things should
> > > be done as well.
> >
> > ARG..
> > forgot about the bucket/sms changes that cliff was in the middle of.
> > we should wait until he
> > a) fully implements the SMS strategy
> > b) uses the pools (I think we was going in this direction)
>
> Yes, apr-util can definitely not go release until the buckets stuff is
> finalized. I swear I'm working on it... just a lot of stuff came up this
> past week.
>
> (I assume by "uses the pools" you mean the free-list stuff, which is what
> I'm working on, but which is not pools in the apr_pool_t sense. There are
> no plans that I know of to make buckets use apr_pool_t's any more than
> they already do.
that's what I mean't
)
>
> --Cliff
>
> --------------------------------------------------------------
> Cliff Woolley
> cliffwoolley@yahoo.com
> Charlottesville, VA
>
--
Ian Holsman IanH@cnet.com
Performance Measurement & Analysis
CNET Networks - (415) 364-8608
Re: Release time?
Posted by Cliff Woolley <cl...@yahoo.com>.
On 19 Sep 2001, Ian Holsman wrote:
> > APR-util can be released on a different schedule from APR, but yes
> > we should move APR-util to release, and all of these things should
> > be done as well.
>
> ARG..
> forgot about the bucket/sms changes that cliff was in the middle of.
> we should wait until he
> a) fully implements the SMS strategy
> b) uses the pools (I think we was going in this direction)
Yes, apr-util can definitely not go release until the buckets stuff is
finalized. I swear I'm working on it... just a lot of stuff came up this
past week.
(I assume by "uses the pools" you mean the free-list stuff, which is what
I'm working on, but which is not pools in the apr_pool_t sense. There are
no plans that I know of to make buckets use apr_pool_t's any more than
they already do.)
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: Release time?
Posted by Ian Holsman <ia...@cnet.com>.
On Wed, 2001-09-19 at 09:47, Ryan Bloom wrote:
> On Wednesday 19 September 2001 09:42 am, Ian Holsman wrote:
> > On Wed, 2001-09-19 at 08:51, Ryan Bloom wrote:
> > > On Wednesday 19 September 2001 08:44 am, Justin Erenkrantz wrote:
> > > > On Wed, Sep 19, 2001 at 08:19:01AM -0700, Ryan Bloom wrote:
> > > > > I would like to move APR to a releasable state finally. To do this,
> > > > > we need to finish the locking API at the very least. Does anybody
> > > > > have other issues that need to be resolved?
> > > >
> > > > I think there was some discussion about apr_mktemp or something. Did
> > > > that get resolved?
> > > >
> > > > Other than that, +1. -- justin
> > >
> > > I haven't resolved that yet, it is on my list of things to do now though.
> >
> > i'd like to get the Doxygen in APR-Util 'makeable' (like it is in apr)
> >
> > i'd also like to get the DBM's split into seperate files (the actual
> > using multiple files can wait until APR 1.1 i guess)
>
> APR-util can be released on a different schedule from APR, but yes we should
> move APR-util to release, and all of these things should be done as well.
>
ARG..
forgot about the bucket/sms changes that cliff was in the middle of.
we should wait until he
a) fully implements the SMS strategy
b) uses the pools (I think we was going in this direction)
> Ryan
> ______________________________________________________________
> Ryan Bloom rbb@apache.org
> Covalent Technologies rbb@covalent.net
> --------------------------------------------------------------
--
Ian Holsman IanH@cnet.com
Performance Measurement & Analysis
CNET Networks - (415) 364-8608
Re: Release time?
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 19 September 2001 09:42 am, Ian Holsman wrote:
> On Wed, 2001-09-19 at 08:51, Ryan Bloom wrote:
> > On Wednesday 19 September 2001 08:44 am, Justin Erenkrantz wrote:
> > > On Wed, Sep 19, 2001 at 08:19:01AM -0700, Ryan Bloom wrote:
> > > > I would like to move APR to a releasable state finally. To do this,
> > > > we need to finish the locking API at the very least. Does anybody
> > > > have other issues that need to be resolved?
> > >
> > > I think there was some discussion about apr_mktemp or something. Did
> > > that get resolved?
> > >
> > > Other than that, +1. -- justin
> >
> > I haven't resolved that yet, it is on my list of things to do now though.
>
> i'd like to get the Doxygen in APR-Util 'makeable' (like it is in apr)
>
> i'd also like to get the DBM's split into seperate files (the actual
> using multiple files can wait until APR 1.1 i guess)
APR-util can be released on a different schedule from APR, but yes we should
move APR-util to release, and all of these things should be done as well.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: Release time?
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 19 September 2001 10:17 am, Greg Stein wrote:
> On Wed, Sep 19, 2001 at 09:42:33AM -0700, Ian Holsman wrote:
> > On Wed, 2001-09-19 at 08:51, Ryan Bloom wrote:
> > > On Wednesday 19 September 2001 08:44 am, Justin Erenkrantz wrote:
> > > > On Wed, Sep 19, 2001 at 08:19:01AM -0700, Ryan Bloom wrote:
> > > > > I would like to move APR to a releasable state finally. To do
> > > > > this, we need to finish the locking API at the very least. Does
> > > > > anybody have other issues that need to be resolved?
> >
> >...
> > i'd like to get the Doxygen in APR-Util 'makeable' (like it is in apr)
> >
> > i'd also like to get the DBM's split into seperate files (the actual
> > using multiple files can wait until APR 1.1 i guess)
>
> We should do the multiple usage, too. There are quite a few problems with
> being forced into the one format that you happened to compile with.
>
> The MD5 and passwd validation stuff still needs to move, crypt needs to be
> handled, and the UUID stuff tweaked. I'll shift that up my priority list if
> we're going for a stable API. I've got a brigade function to write.
What brigade function?
> However, we can do an official beta and *add* APIs between beta and gold.
We can _ADD_ APIs anytime, as long as the current APIs don't change.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: Release time?
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 19, 2001 at 09:42:33AM -0700, Ian Holsman wrote:
> On Wed, 2001-09-19 at 08:51, Ryan Bloom wrote:
> > On Wednesday 19 September 2001 08:44 am, Justin Erenkrantz wrote:
> > > On Wed, Sep 19, 2001 at 08:19:01AM -0700, Ryan Bloom wrote:
> > > > I would like to move APR to a releasable state finally. To do this, we
> > > > need to finish the locking API at the very least. Does anybody have
> > > > other issues that need to be resolved?
>...
> i'd like to get the Doxygen in APR-Util 'makeable' (like it is in apr)
>
> i'd also like to get the DBM's split into seperate files (the actual
> using multiple files can wait until APR 1.1 i guess)
We should do the multiple usage, too. There are quite a few problems with
being forced into the one format that you happened to compile with.
The MD5 and passwd validation stuff still needs to move, crypt needs to be
handled, and the UUID stuff tweaked. I'll shift that up my priority list if
we're going for a stable API. I've got a brigade function to write.
As Bill mentioned, we also have some versioning stuff to do.
All this stuff is in apr(-util)/STATUS
However, we can do an official beta and *add* APIs between beta and gold.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Release time?
Posted by Ian Holsman <ia...@cnet.com>.
On Wed, 2001-09-19 at 08:51, Ryan Bloom wrote:
> On Wednesday 19 September 2001 08:44 am, Justin Erenkrantz wrote:
> > On Wed, Sep 19, 2001 at 08:19:01AM -0700, Ryan Bloom wrote:
> > > I would like to move APR to a releasable state finally. To do this, we
> > > need to finish the locking API at the very least. Does anybody have
> > > other issues that need to be resolved?
> >
> > I think there was some discussion about apr_mktemp or something. Did
> > that get resolved?
> >
> > Other than that, +1. -- justin
>
> I haven't resolved that yet, it is on my list of things to do now though.
>
i'd like to get the Doxygen in APR-Util 'makeable' (like it is in apr)
i'd also like to get the DBM's split into seperate files (the actual
using multiple files can wait until APR 1.1 i guess)
> Ryan
>
> ______________________________________________________________
> Ryan Bloom rbb@apache.org
> Covalent Technologies rbb@covalent.net
> --------------------------------------------------------------
--
Ian Holsman IanH@cnet.com
Performance Measurement & Analysis
CNET Networks - (415) 364-8608
Re: Release time?
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 19 September 2001 08:44 am, Justin Erenkrantz wrote:
> On Wed, Sep 19, 2001 at 08:19:01AM -0700, Ryan Bloom wrote:
> > I would like to move APR to a releasable state finally. To do this, we
> > need to finish the locking API at the very least. Does anybody have
> > other issues that need to be resolved?
>
> I think there was some discussion about apr_mktemp or something. Did
> that get resolved?
>
> Other than that, +1. -- justin
I haven't resolved that yet, it is on my list of things to do now though.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: Release time?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Justin Erenkrantz" <je...@ebuilt.com>
Sent: Wednesday, September 19, 2001 10:44 AM
> On Wed, Sep 19, 2001 at 08:19:01AM -0700, Ryan Bloom wrote:
> >
> > I would like to move APR to a releasable state finally. To do this, we need to
> > finish the locking API at the very least. Does anybody have other issues that
> > need to be resolved?
>
> I think there was some discussion about apr_mktemp or something. Did
> that get resolved?
No, and I need something for win32 on that. Mladen offered something, but I'm
still scrutinizing, I just don't quite like the solution yet.
Re: Release time?
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Sep 19, 2001 at 08:19:01AM -0700, Ryan Bloom wrote:
>
> I would like to move APR to a releasable state finally. To do this, we need to
> finish the locking API at the very least. Does anybody have other issues that
> need to be resolved?
I think there was some discussion about apr_mktemp or something. Did
that get resolved?
Other than that, +1. -- justin
Re: Release time?
Posted by Branko Čibej <br...@xbc.nu>.
Ryan Bloom wrote:
>I would like to move APR to a releasable state finally. To do this, we need to
>finish the locking API at the very least. Does anybody have other issues that
>need to be resolved?
>
Have all the functions been renamed according to the new naming scheme?
I seem to recall the status posts still mention pending renames.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
Re: Release time?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Ryan Bloom" <rb...@covalent.net>
Sent: Wednesday, September 19, 2001 10:19 AM
> I would like to move APR to a releasable state finally. To do this, we need to
> finish the locking API at the very least. Does anybody have other issues that
> need to be resolved?
Versioning.
? Feature testing ?
? Anyone have a good idea on how to close the hproc in the win32 apr_proc_t ?
Folks, review STATUS. Clear out the stuff you added that you can live without
(or at least indicate that it's a wanna, not a haveto, if that's the case.)
Pull what you've fixed.
Re: Release time?
Posted by Aaron Bannert <aa...@clove.org>.
On Wed, Sep 19, 2001 at 08:19:01AM -0700, Ryan Bloom wrote:
> I would like to move APR to a releasable state finally. To do this, we need to
> finish the locking API at the very least. Does anybody have other issues that
> need to be resolved?
I'd like to fix the return status in apr_thread_exit(), and I plan to
today or tomorrow.
-aaron
Re: Release time?
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 19 September 2001 09:20 am, Justin Erenkrantz wrote:
> On Wed, Sep 19, 2001 at 08:19:01AM -0700, Ryan Bloom wrote:
> > I would like to move APR to a releasable state finally. To do this, we
> > need to finish the locking API at the very least. Does anybody have
> > other issues that need to be resolved?
>
> Oh, I'd like to consider Sander's pool re-implementation and
> Madhu's shared memory patch. Both of these don't change the API,
> so I don't think it affects the "releasability" of APR.
>
> (I think releasable state means that no API changes occur without
> three +1s - code may still be C-T-R - that's my take on it...)
>
> They can wait until I get around to it, or someone beats me to it.
> -- justin
Once APR is released, no APIs can be changed ever, without a VERY good
reason for the change. We can add API's whenever we want, but removing
an API from a library is an absolute no-no.
This is one reason I want the locking done before release. I would like to remove
the old useless API.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
RE: Release time?
Posted by Sander Striker <st...@apache.org>.
> From: Justin Erenkrantz [mailto:jerenkrantz@ebuilt.com]
> Sent: 19 September 2001 18:20
> On Wed, Sep 19, 2001 at 08:19:01AM -0700, Ryan Bloom wrote:
> >
> > I would like to move APR to a releasable state finally. To do
> this, we need to
> > finish the locking API at the very least. Does anybody have
> other issues that
> > need to be resolved?
>
> Oh, I'd like to consider Sander's pool re-implementation and
Shall I repost it? [I've updated it a bit]
Ian scheduled to do some perf testing with it, don't know if
he got around to doing that.
> Madhu's shared memory patch. Both of these don't change the API,
> so I don't think it affects the "releasability" of APR.
>
> (I think releasable state means that no API changes occur without
> three +1s - code may still be C-T-R - that's my take on it...)
>
> They can wait until I get around to it, or someone beats me to it.
> -- justin
Sander
Re: Release time?
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Wed, Sep 19, 2001 at 08:19:01AM -0700, Ryan Bloom wrote:
>
> I would like to move APR to a releasable state finally. To do this, we need to
> finish the locking API at the very least. Does anybody have other issues that
> need to be resolved?
Oh, I'd like to consider Sander's pool re-implementation and
Madhu's shared memory patch. Both of these don't change the API,
so I don't think it affects the "releasability" of APR.
(I think releasable state means that no API changes occur without
three +1s - code may still be C-T-R - that's my take on it...)
They can wait until I get around to it, or someone beats me to it.
-- justin
Re: Release time?
Posted by Aaron Bannert <aa...@clove.org>.
On Wed, Sep 19, 2001 at 06:26:16PM +0200, Sander Striker wrote:
> Other issues before release might be going over all the functions
> one more time and check for consistency in argument ordering.
> Changes to ordering have been postponed because the functions
> were being used in httpd and elsewhere, but I think the release
> should be as consistent as possible with respect to argument
> ordering for ease of use. I realize this impacts a big ammount
> of code, but still think it is worth it. If it is out there
> there is no chance of changing the API anymore.
That is a good point. Another thing to check would be things like
element type ordering in structs -- ie make sure apr_pool_t's are
the first element (I remember something about this from a thread
a long time ago. I don't know if it's still necessary, though. It
had something to do with accessing private data structures).
-aaron
Re: Release time?
Posted by Ryan Bloom <rb...@covalent.net>.
On Wednesday 19 September 2001 09:26 am, Sander Striker wrote:
> > -----Original Message-----
> > From: Ryan Bloom [mailto:rbb@covalent.net]
> > Sent: 19 September 2001 17:19
> >
> > I would like to move APR to a releasable state finally. To do
> > this, we need to
> > finish the locking API at the very least. Does anybody have
> > other issues that
> > need to be resolved?
> >
> > Ryan
>
> Do we wish to keep or remove sms?
> I realize a fair amount of time went into it, but performance
> wise it didn't cut it (due to the extra indirection). There
> might be applications for it, but right now it is only extra
> baggage. Is anyone using sms currently, or planning to?
I would personally like to see it removed. I do think that an SMS-like
implementation is a good thing, but I don't think what we have is quite it.
I am very careful about putting an API into a released version of APR,
because once it is there, it is there forever.
> Other issues before release might be going over all the functions
> one more time and check for consistency in argument ordering.
> Changes to ordering have been postponed because the functions
> were being used in httpd and elsewhere, but I think the release
> should be as consistent as possible with respect to argument
> ordering for ease of use. I realize this impacts a big ammount
> of code, but still think it is worth it. If it is out there
> there is no chance of changing the API anymore.
I agree. This kind of thing needs to be done. If it can be done with a
perl script, so much the better.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: Release time?
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Sep 19, 2001 at 01:29:37PM -0400, Bill Stoddard wrote:
> > > -----Original Message-----
> > > From: Ryan Bloom [mailto:rbb@covalent.net]
> > > Sent: 19 September 2001 17:19
> >
> > > I would like to move APR to a releasable state finally. To do
> > > this, we need to
> > > finish the locking API at the very least. Does anybody have
> > > other issues that
> > > need to be resolved?
> > >
> > > Ryan
> >
> > Do we wish to keep or remove sms?
>
> +1 on removing it.
+1 on removal. It can go back at some future time when somebody shows it has
specific benefits.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Removing SMS from APR, WAS: RE: Release time?
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Sep 20, 2001 at 12:25:54AM +0200, Sander Striker wrote:
> Ok, if noone objects I'll remove it it the day after tomorrow.
> That is, when noone beats me to it.
I thought Cliff was still playing with SMS. Cliff? -- justin
Re: Removing SMS from APR, WAS: RE: Release time?
Posted by Cliff Woolley <cl...@yahoo.com>.
On Wed, 19 Sep 2001, Cliff Woolley wrote:
> Don't remove them it I've un-depended buckets on it!! :)
s/them it/it until/
Re: Removing SMS from APR, WAS: RE: Release time?
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 20 Sep 2001, Sander Striker wrote:
> > > Do we wish to keep or remove sms?
> >
> > +1 on removing it.
>
> Ok, if noone objects I'll remove it it the day after tomorrow.
> That is, when noone beats me to it.
Don't remove them it I've un-depended buckets on it!! :)
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Removing SMS from APR, WAS: RE: Release time?
Posted by Sander Striker <st...@apache.org>.
> From: Bill Stoddard [mailto:bill@wstoddard.com]
> Sent: 19 September 2001 19:30
> > > -----Original Message-----
> > > From: Ryan Bloom [mailto:rbb@covalent.net]
> > > Sent: 19 September 2001 17:19
> >
> > > I would like to move APR to a releasable state finally. To do
> > > this, we need to
> > > finish the locking API at the very least. Does anybody have
> > > other issues that
> > > need to be resolved?
> > >
> > > Ryan
> >
> > Do we wish to keep or remove sms?
>
> +1 on removing it.
Ok, if noone objects I'll remove it it the day after tomorrow.
That is, when noone beats me to it.
Sander
Re: Release time?
Posted by Bill Stoddard <bi...@wstoddard.com>.
> > -----Original Message-----
> > From: Ryan Bloom [mailto:rbb@covalent.net]
> > Sent: 19 September 2001 17:19
>
> > I would like to move APR to a releasable state finally. To do
> > this, we need to
> > finish the locking API at the very least. Does anybody have
> > other issues that
> > need to be resolved?
> >
> > Ryan
>
> Do we wish to keep or remove sms?
+1 on removing it.
Bill
RE: Release time?
Posted by Sander Striker <st...@apache.org>.
> -----Original Message-----
> From: Ryan Bloom [mailto:rbb@covalent.net]
> Sent: 19 September 2001 17:19
> I would like to move APR to a releasable state finally. To do
> this, we need to
> finish the locking API at the very least. Does anybody have
> other issues that
> need to be resolved?
>
> Ryan
Do we wish to keep or remove sms?
I realize a fair amount of time went into it, but performance
wise it didn't cut it (due to the extra indirection). There
might be applications for it, but right now it is only extra
baggage. Is anyone using sms currently, or planning to?
Other issues before release might be going over all the functions
one more time and check for consistency in argument ordering.
Changes to ordering have been postponed because the functions
were being used in httpd and elsewhere, but I think the release
should be as consistent as possible with respect to argument
ordering for ease of use. I realize this impacts a big ammount
of code, but still think it is worth it. If it is out there
there is no chance of changing the API anymore.
Sander