I've been working on this, and I don't see a solution. I have the parameter
added to child_init, and the structures get allocated. But, that doesn't solve
the problem, because many lock types just can't be used across an
apr_proc_create.
The only solution I can think of for this is to remove A
On Friday, July 12, 2002, at 07:05 PM, William A. Rowe, Jr. wrote:
At 08:49 PM 7/12/2002, [EMAIL PROTECTED] wrote:
2) Renaming the function to get rid of apr_time_t vs time_t
confusion,
but keep it ambigious and make no contract with the user
about the
units repr
At 08:49 PM 7/12/2002, [EMAIL PROTECTED] wrote:
2) Renaming the function to get rid of apr_time_t vs time_t
confusion,
but keep it ambigious and make no contract with the user
about the
units represented. Needs a better suggestion than apr_timeval_t.
-
On Thu, Jul 11, 2002 at 03:20:33PM -0700, Ryan Bloom wrote:
> > Bumping the MMN works for things like Apache, but not for flood,
> > subversion, or any of the countless other APR-based apps that have
> > sprung up lately.
> >
> > I'll agree that changing the typename doesn't solve the problem of
>
At 12:29 PM 7/12/2002, Ryan Bloom wrote:
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
>
> Then how about apr_buseconds_t? This makes it absolutely clear that the
> type contains some number of buseconds [whatever those are... open the
> doxygen pages... ah... +/-number of binary microsec
Ryan Bloom wrote:
Can we start this conversation over completely?
I think we just did that yesterday. :-)
Currently we are
arguing over names for a new type, but I don't think we actually know
the problem that we are trying to solve.
The problem is that don't have a consensus on whether to name
the
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
>
> At 07:22 PM 7/11/2002, Ryan Bloom wrote:
> > > From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
> > > At 07:34 PM 7/11/2002, Justin Erenkrantz wrote:
> > >
> > > >Not quite opaque in that you can still compute deltas via a
> > > >subtr
At 07:22 PM 7/11/2002, Ryan Bloom wrote:
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
> At 07:34 PM 7/11/2002, Justin Erenkrantz wrote:
>
> >Not quite opaque in that you can still compute deltas via a
> >subtraction, but that to understand the quantities, you must place
> >it through a fu
> From: Brian Pane [mailto:[EMAIL PROTECTED]
>
> On Thu, 2002-07-11 at 17:22, Ryan Bloom wrote:
> > > From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
> > > At 07:34 PM 7/11/2002, Justin Erenkrantz wrote:
> > >
> > > >Not quite opaque in that you can still compute deltas via a
> > > >subtracti
On Thu, 2002-07-11 at 17:22, Ryan Bloom wrote:
> > From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
> > At 07:34 PM 7/11/2002, Justin Erenkrantz wrote:
> >
> > >Not quite opaque in that you can still compute deltas via a
> > >subtraction, but that to understand the quantities, you must place
>
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
> At 07:34 PM 7/11/2002, Justin Erenkrantz wrote:
>
> >Not quite opaque in that you can still compute deltas via a
> >subtraction, but that to understand the quantities, you must place
> >it through a function/macro. Brian has already convert
> It isn't supposed to be funny. I want to know why APR folks seem to think
> that other applications of APR are as important, or even remotely as
> important, as the performance of httpd. I want to know because all of the
decisions
> that have been made in the name of other application's "needs
Irrelevant. If you want httpd to use APR, then it had better not make
httpd
worse for no good reason. If there is a reason, then I want it
documented
in the code. If not, if it is just the whim of some folks using APR,
then
I will fork the httpd project away from APR.
Roy, isn't this a bit of
> From: Roy T. Fielding [mailto:[EMAIL PROTECTED]
> Sent: 12 July 2002 04:20
>> I will say the very same thing Ryan did several weeks [months?] ago.
>> Where were you for the last two years?
>
> Complaining about how fucked up the design decisions were for apr_time_t.
> Its in the archives. Pe
I will say the very same thing Ryan did several weeks [months?] ago.
Where were you for the last two years?
Complaining about how fucked up the design decisions were for apr_time_t.
Its in the archives. People didn't want to deal with it before due to
more pressing concerns. 2.0 is now out, so
Um, Roy? WTF are you talking about?
From apr/time/unix/time.c:
APR_DECLARE(apr_time_t) apr_time_now(void)
{
struct timeval tv;
gettimeofday(&tv, NULL);
return tv.tv_sec * APR_USEC_PER_SEC + tv.tv_usec;
}
And as for "demonstrated needs," you're thinking too Apache-centric by a
longshot.
At 07:34 PM 7/11/2002, Justin Erenkrantz wrote:
Not quite opaque in that you can still compute deltas via a
subtraction, but that to understand the quantities, you must place
it through a function/macro. Brian has already converted httpd
to this model. -- justin
OK... after much hand waving today
On 12 Jul 2002 [EMAIL PROTECTED] wrote:
> + [fielding; Cliff says he has a sample app. I still don't know how
> + he uses them without making implementation assumptions about
> + apr_time_t everywhere (there is no print routine for microsecond
> + resolution), but I
Roy,
I will say the very same thing Ryan did several weeks [months?] ago.
Where were you for the last two years?
The questions on the table in APR is;
1. are we the special interest of httpd alone? Are we their sub-project?
2. was this already thought out and debated, and this design w
On Thu, Jul 11, 2002 at 05:31:29PM -0700, Aaron Bannert wrote:
> On Fri, Jul 12, 2002 at 12:13:54AM -, Justin Erenkrantz wrote:
> > jerenkrantz2002/07/11 17:13:54
> >
> > Modified:.STATUS
> > Log:
> > IMHO, apr_time_t should be treated as an opaque value. The library
>
On Fri, Jul 12, 2002 at 12:13:54AM -, Justin Erenkrantz wrote:
> jerenkrantz2002/07/11 17:13:54
>
> Modified:.STATUS
> Log:
> IMHO, apr_time_t should be treated as an opaque value. The library should
> be
> free to change the implementation details whenever it wants.
> The fact that APR has provided me with a platform-neutral way to get
> high-resolution time has been a *huge* boon to my work. While I realize
> this is a limited example, the same applies to many other use cases I can
> think of.
>
> Stop hand-waving-saying-we're-hand-waving, please. IMO the
> + others that I haven't checked. In any case, since we use the
> + system's time_t time() function to get the time value everywhere
> + except Win32 w/SYSTEMTIME, we only ever have a resolution of
> + seconds or milliseconds. So, why the hell are we storing usec
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > @@ -104,6 +104,12 @@
> > system's time_t time() function to get the time value
> everywhere
> > except Win32 w/SYSTEMTIME, we only ever have a resolution
of
> > seconds or milliseconds. So, why the hell are
Francisco, CA
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 11, 2002 4:41 PM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: apr STATUS
>
> brianp 2002/07/11 16:40:48
>
> Modified:.STATUS
> L
Ryan Bloom wrote:
Bumping the MMN works for things like Apache, but not for flood,
subversion, or any of the countless other APR-based apps that have
sprung up lately.
I'll agree that changing the typename doesn't solve the problem of
mismatched binary compatibility, but it does make it obvious to
> Bumping the MMN works for things like Apache, but not for flood,
> subversion, or any of the countless other APR-based apps that have
> sprung up lately.
>
> I'll agree that changing the typename doesn't solve the problem of
> mismatched binary compatibility, but it does make it obvious to the
a
On Thu, Jul 11, 2002 at 01:37:14PM -0700, Brian Pane wrote:
> >Let's take a typical scenario:
> >
> >- Acme software releases mod_acme 2.0 to work with Apache 2.0
> >- They distribute a binary version of this module to work specifically
> > with 2.0.39 (the only version out that isn't susceptible
Aaron Bannert wrote:
Let's take a typical scenario:
- Acme software releases mod_acme 2.0 to work with Apache 2.0
- They distribute a binary version of this module to work specifically
with 2.0.39 (the only version out that isn't susceptible to the
chunked-encoding vulnerability).
- Apache 2.0.
On 11 Jul 2002 [EMAIL PROTECTED] wrote:
> + -1: aaron [veto for reusing the apr_time_t identifier for a new
> use.
> +I'm ok with apr_timeval_t.]
If we're avoiding apr_time_t because of confusion with the POSIX time_t,
it makes no sense whatsoever to use "apr_time
William A. Rowe, Jr. wrote:
At 11:37 AM 7/11/2002, you wrote:
brianp 2002/07/11 09:37:50
Modified:.STATUS
Log:
Added vote on apr_time_t naming
2) Renaming the function to get rid of apr_time_t vs time_t
confusion,
which wrowe suggests apr_butime_t [bina
On Thu, Jul 11, 2002 at 02:35:04PM -0500, William A. Rowe, Jr. wrote:
> In this case, semantic compatibility has NO IMPACT on binary
> compatibility. The code will remain binary compatible, even though
> this change breaks the behavior.
>
> APR changes... we are pre-1.0 and our developer/consumer
At 02:20 PM 7/11/2002, Aaron Bannert wrote:
Just to clarify the technical reason for vetoing the use of apr_time_t
with a new implementation. The reason I veto this is because I don't
want us to maintain binary compatibility while we're not maintaining
semantic compatibility. There are programs out
Just to clarify the technical reason for vetoing the use of apr_time_t
with a new implementation. The reason I veto this is because I don't
want us to maintain binary compatibility while we're not maintaining
semantic compatibility. There are programs out there that use APR's
apr_time_t and will tr
At 11:37 AM 7/11/2002, you wrote:
brianp 2002/07/11 09:37:50
Modified:.STATUS
Log:
Added vote on apr_time_t naming
2) Renaming the function to get rid of apr_time_t vs time_t
confusion,
which wrowe suggests apr_butime_t [binary microtime].
+
"William A. Rowe, Jr." <[EMAIL PROTECTED]> writes:
> Are these also for consideration in the 2.0.34 release?
> >gregames02/04/01 13:07:13
> >
> > Modified:buildapr_hints.m4
> >.STATUS
> > Log:
> > FreeBSD: use fcntl cross-process locks by default. Make n
Are these also for consideration in the 2.0.34 release?
Bill
gregames02/04/01 13:07:13
Modified:buildapr_hints.m4
.STATUS
Log:
FreeBSD: use fcntl cross-process locks by default. Make note of problems
experienced with flock and SysV sems.
Revision Chan
[EMAIL PROTECTED] wrote:
>
> gregames02/04/01 13:07:13
>
> Modified:buildapr_hints.m4
>.STATUS
> Log:
> FreeBSD: use fcntl cross-process locks by default. Make note of problems
> experienced with flock and SysV sems.
I'll update this as appropriate af
[EMAIL PROTECTED] writes:
> gregames02/04/01 13:07:13
>
> Modified:buildapr_hints.m4
>.STATUS
> Log:
> FreeBSD: use fcntl cross-process locks by default. Make note of problems
> experienced with flock and SysV sems.
I just committed a fix for flock-ba
>From out in left field... this was sitting amidst my drafts. Dunno how
relevant it still is.
From: "Aaron Bannert" <[EMAIL PROTECTED]>
Sent: Tuesday, February 05, 2002 10:30 AM
> On Wed, Feb 06, 2002 at 12:07:58AM +1000, Brian Havard wrote:
> >
> > On OS/2 the only native mechanism that has cr
On Mon, Feb 11, 2002 at 12:44:17AM +1000, Brian Havard wrote:
> Ok, so the cross-process lock is essentially a performance optimization for
> when you're running single threaded processes on a multi-threading capable
> system that doesn't have an efficient global lock mechanism.
>
> If that's th
On Tue, 5 Feb 2002 08:30:22 -0800, Aaron Bannert wrote:
>On Wed, Feb 06, 2002 at 12:07:58AM +1000, Brian Havard wrote:
>> On OS/2 the only native mechanism that has cross-process lock behaviour is
>> file locking (which is yuck because then you have to have a lock file). In
>> fact I suspect the o
On Wed, Feb 06, 2002 at 12:07:58AM +1000, Brian Havard wrote:
> On OS/2 the only native mechanism that has cross-process lock behaviour is
> file locking (which is yuck because then you have to have a lock file). In
> fact I suspect the only reason we have cross-process locks at all is that
> some
On Mon, 4 Feb 2002 11:17:38 -0800, Aaron Bannert wrote:
>Can someone please comment on the state of the OS/2 and Netware lock
>implementation? Is it unnecessary or even senseless to implement
>a cross-process lock on Netware (where I've been told there are
>only threads)?
On OS/2 the only native
Can someone please comment on the state of the OS/2 and Netware lock
implementation? Is it unnecessary or even senseless to implement
a cross-process lock on Netware (where I've been told there are
only threads)?
-aaron
On Mon, Feb 04, 2002 at 07:15:20PM -, [EMAIL PROTECTED] wrote:
> aaron
On Tue, Dec 25, 2001 at 09:47:12PM -0500, Jeff Trawick wrote:
> Other than performance, why should the caller care? The lock can't
> block. Unbeknownst to the caller we or libc get locks on other
> callers.
>
> Still curious,
Hmm. Let me try and restate it. It's a feeling that doing this
woul
Justin Erenkrantz <[EMAIL PROTECTED]> writes:
> On Tue, Dec 25, 2001 at 08:19:19PM -0500, Jeff Trawick wrote:
> > > I'd like to see this as a lock creation option. Something like
> > > a flag - say, APR_LOCK_VERIFY or some such. I don't think we should
> > > do the acquire/release unless asked f
On Tue, Dec 25, 2001 at 08:19:19PM -0500, Jeff Trawick wrote:
> > I'd like to see this as a lock creation option. Something like
> > a flag - say, APR_LOCK_VERIFY or some such. I don't think we should
> > do the acquire/release unless asked for by the caller. I think
> > this might mean changing
Justin Erenkrantz <[EMAIL PROTECTED]> writes:
> > Maybe we should try to acquire/release the lock during create time,
> > and return the acquire errno if that fails. Maybe the error codes
> > differ between systems but at least we fail ahead of time.
> >
> > That sounds easy and harmless to me.
On Fri, Dec 21, 2001 at 07:57:38AM -0500, Jeff Trawick wrote:
> [EMAIL PROTECTED] writes:
>
> > jerenkrantz01/12/12 02:05:54
> >
> > Modified:.STATUS
> > Log:
> > Not a big deal, but worth noting. If anyone has an idea on how to
> > detect this, it'd be general goodness t
[EMAIL PROTECTED] writes:
> jerenkrantz01/12/12 02:05:54
>
> Modified:.STATUS
> Log:
> Not a big deal, but worth noting. If anyone has an idea on how to
> detect this, it'd be general goodness to error out when we create
> the lock rather than waiting to error out when
On Mon, Dec 10, 2001 at 02:23:53PM -0500, Greg Ames wrote:
> [EMAIL PROTECTED] wrote:
> > +Status: Justin has tracked down a FreeBSD kernel hacker
> > +([EMAIL PROTECTED]) and we've isolated some issues
> > +within src/lib/libc_r/uthread/uthread_sendfil
[EMAIL PROTECTED] wrote:
> And, you thought there wasn't going to be anything happening with this
> item (FreeBSD and threading support)? Ha!
> +Status: Justin has tracked down a FreeBSD kernel hacker
> +([EMAIL PROTECTED]) and we've isolated some issues
> +
On Wednesday 22 August 2001 21:20, Greg Stein wrote:
> On Thu, Aug 23, 2001 at 04:03:37AM -, [EMAIL PROTECTED] wrote:
>
> The full text of that item:
>
> * configure.in does post-processing on the AC_OUTPUT files (for
> VPATH support). This means that config.status doesn't do the
>
On Thu, Aug 23, 2001 at 04:03:37AM -, [EMAIL PROTECTED] wrote:
>...
> @@ -100,6 +104,7 @@
> built-in macro processing is much more powerful, and
> combined with the include facility, generating Makefiles
> becomes simpler and faster.
> +
> ALLOC_USE_MALLOC would be faster than the current pool code for
> a threaded APR (but, I'm not sure).
>Status: Justin volunteers
> +David and Sander are working on some stuff that
> +should be ready Real Soon Now (TM). Sander ha
On Wed, Jun 27, 2001 at 10:17:40PM -0700, [EMAIL PROTECTED] wrote:
>
> Not to be contrary, but this can be easily resolved, by passing in a
> simple flag when creating a pool. That flag tells us whether or not we
> should lock when using the pool.
The real point is that we have a global freelist
Not to be contrary, but this can be easily resolved, by passing in a
simple flag when creating a pool. That flag tells us whether or not we
should lock when using the pool.
Ryan
On 28 Jun 2001 [EMAIL PROTECTED] wrote:
> jerenkrantz01/06/27 22:14:30
>
> Modified:.STATUS
> Lo
Right. What Cliff said.
We aren't going to provide a replacement for it, just say whether it is
available, and get it linked in from the right library (it can live in
several places).
crypt() is a rather poor hash function. We have MD5 and SHA1 instead.
Cheers,
-g
On Thu, May 31, 2001 at 12:37:
On Wed, 30 May 2001, Justin Erenkrantz wrote:
> I think that wherever these other crypto functions go, so should
> crypt().
Yeah, but...
> crypt() is slightly different than the other crypto algorithms as
> my systems have it as a standard library call. But, not all systems
> will have it.
Whi
On Thu, May 31, 2001 at 12:14:02AM -0400, Cliff Woolley wrote:
> On 31 May 2001 [EMAIL PROTECTED] wrote:
>
> > @@ -65,6 +65,8 @@
> >* add apr_crypt() and APR_HAS_CRYPT for apps to determine whether the
> > crypt() function is available, and a way to call it (whether it is
> >
On 31 May 2001 [EMAIL PROTECTED] wrote:
> @@ -65,6 +65,8 @@
>* add apr_crypt() and APR_HAS_CRYPT for apps to determine whether the
> crypt() function is available, and a way to call it (whether it is
> located in libc, libcrypt, or libufc)
> + Justin says: Should
[EMAIL PROTECTED] wrote:
>
> On Fri, 27 Apr 2001, Ben Laurie wrote:
>
> > [EMAIL PROTECTED] wrote:
> > > +* add a pool argument to setaside() to tell a bucket "do whatever
> > > + you need to do, to ensure that you survive as long as this
> > > + pool." Immortal and heap bucke
On Fri, 27 Apr 2001, Ben Laurie wrote:
> [EMAIL PROTECTED] wrote:
> > +* add a pool argument to setaside() to tell a bucket "do whatever
> > + you need to do, to ensure that you survive as long as this
> > + pool." Immortal and heap buckets never have work. File, socket,
> >
[EMAIL PROTECTED] wrote:
> +* add a pool argument to setaside() to tell a bucket "do whatever
> + you need to do, to ensure that you survive as long as this
> + pool." Immortal and heap buckets never have work. File, socket,
> + mmap, pipe, and pool buckets can do nothing
> > > +* I think apr_open_stderr() and friends dup() the descriptor. That
> > > + would allow the new/returned file to be closed (via pool cleanup
> > > + or manually) without accidentally closing stderr/out.
> >
> > The goal of those functions is to actually get stderr, stdou
On Sun, Feb 04, 2001 at 01:54:52PM -0800, [EMAIL PROTECTED] wrote:
>
> > +* I think apr_open_stderr() and friends dup() the descriptor. That
> > + would allow the new/returned file to be closed (via pool cleanup
> > + or manually) without accidentally closing stderr/out.
>
> T
> +* I think apr_open_stderr() and friends dup() the descriptor. That
> + would allow the new/returned file to be closed (via pool cleanup
> + or manually) without accidentally closing stderr/out.
The goal of those functions is to actually get stderr, stdout, stdin into
an apr
On Sun, 28 Jan 2001, David Reid wrote:
> Are we not using it as we haven't come across the case where we need it yet?
> If that's the case then I'll remove my +1 but from the note it looked as if
> we just weren't ever using it.
We aren't using the type parameter because nobody has had the time t
Are we not using it as we haven't come across the case where we need it yet?
If that's the case then I'll remove my +1 but from the note it looked as if
we just weren't ever using it.
david
> @@ -62,7 +62,13 @@
> - It ignores the "type" parameter, so toss it.
> - The fname par
Nevermind, there was nothing to do. Good job Will. :-)
Ryan
On Wed, 17 Jan 2001 [EMAIL PROTECTED] wrote:
>
> I'll get this building again now. I just have to update my local copies.
>
> Ryan
>
> On Wed, 17 Jan 2001, William A. Rowe, Jr. wrote:
>
> > > +++ STATUS 2001/01/18 02:25:0
I'll get this building again now. I just have to update my local copies.
Ryan
On Wed, 17 Jan 2001, William A. Rowe, Jr. wrote:
> > +++ STATUS2001/01/18 02:25:06 1.22
> >APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS:
> >
> > Those for adding apr/src/
> +++ STATUS 2001/01/18 02:25:06 1.22
>APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS:
>
> Those for adding apr/src/: gstein, jim, brane
> + Those for removing apr-util/src/ : wrowe, rbb, dreid, stoddard,
> fielding
I have completed this task. R
Wow, either my plea for a vote worked, or we just got lucky. Thanks
Bill. :-)
Ryan
On 17 Jan 2001 [EMAIL PROTECTED] wrote:
> stoddard01/01/17 12:39:28
>
> Modified:.STATUS
> Log:
> Vote
>
> Revision ChangesPath
> 1.21 +2 -2 apr/STATUS
>
> Inde
> brane 01/01/14 16:28:05
>
> Modified:.STATUS
> Log:
> This vote ends on Wednesday ... which wednesday?
This Wednesday, later tonight (once we have one vote more or less).
At 10pm CST (so I can get to work.)
These have sat in status well over two months, anyone who doesn
> > > Modified:.STATUS
> > > +* apr_create_lock() changes:
> > ...
> > > + - The fname param is allowed to be NULL on the Unix platform.
> >
> > feature, not bug... Do you mean that the semantics associated with
> > this ("make up a file for me if you need to, APR") ar
> +* apr_create_lock() changes:
> + - It ignores the "type" parameter, so toss it.
> + - The fname param is allowed to be NULL on the Unix platform.
> +Change it to always use the passed value, and check callers.
These are in there by design. The type parameter didn
On Thu, Dec 14, 2000 at 09:48:56AM -0500, Jeff Trawick wrote:
> [EMAIL PROTECTED] writes:
>
> > gstein 00/12/14 03:10:26
> >
> > Modified:.STATUS
> > +* apr_create_lock() changes:
> ...
> > + - The fname param is allowed to be NULL on the Unix platform.
>
> featur
[EMAIL PROTECTED] writes:
> gstein 00/12/14 03:10:26
>
> Modified:.STATUS
> +* apr_create_lock() changes:
...
> + - The fname param is allowed to be NULL on the Unix platform.
feature, not bug... Do you mean that the semantics associated with
this ("make up a fil
On 8 Dec 2000 [EMAIL PROTECTED] wrote:
> rbb 00/12/08 06:30:42
>
> Modified:.STATUS
> Log:
> As I recall, there were three or four people who thought the current
> Apache build system was too complex, and at least one who didn't like
> the current APR-Util build syste
On Thu, Dec 07, 2000 at 06:41:37AM -0800, [EMAIL PROTECTED] wrote:
>...
> > +* snarf rules.mk(.in) from APRUTIL to simplify makefiles
> > +Status: Greg +1 (volunteers)
>
> Slow down there cow-boy. :-) We had this discussion once on the list,
> and although a few people liked the
> +* use libtool
> +Status: Greg +1 (volunteers)
As much as I hate libtool, I can agree to this, but I would ask that it
wait until Jim has a chance to voice his opinion, because I know he hates
libtool.
> +
> +* snarf rules.mk(.in) from APRUTIL to simplify makefiles
>
> > > Q. Now that APRUTIL exists, may we please move hooks (a
> > generally useful
> > > entity) into that lib (and put this issue back into util?
> >
> > I think we are just waiting for some people on dev to decide how to move
> > the code out of Apache and into apr-utils. Greg and I have
On Sat, Dec 02, 2000 at 11:22:54PM -0600, William A. Rowe, Jr. wrote:
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > Sent: Saturday, December 02, 2000 11:19 PM
> >
> > > >* API documentation
> > > > -Status: Ben Laurie has written some hooks documentation
> > > > -
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Saturday, December 02, 2000 11:19 PM
>
> > >* API documentation
> > > -Status: Ben Laurie has written some hooks documentation
> > > -(apache-2.0/htdocs/hooks.html)
> >
> > Q. Now that APRUTIL exists, may we
> >* API documentation
> > -Status: Ben Laurie has written some hooks documentation
> > -(apache-2.0/htdocs/hooks.html)
>
> Q. Now that APRUTIL exists, may we please move hooks (a generally useful
> entity) into that lib (and put this issue back into util?
I thin
> rbb 00/12/02 19:31:12
>
> Modified:.STATUS
> Log:
> This STATUS item doesn't belong in APR.
>
>* API documentation
> -Status: Ben Laurie has written some hooks documentation
> -(apache-2.0/htdocs/hooks.html)
Q. Now that APRUTIL exists, m
On Thu, 30 Nov 2000, Greg Stein wrote:
> Given the mapping you list below, are you considering a tighter
> formalization of the namespaces *within* APR? For example, all file
> functions would be apr_file_* ?
>
> I'm -0 on that, but some targeted renames (like the one below) would be a
> Good Thi
Given the mapping you list below, are you considering a tighter
formalization of the namespaces *within* APR? For example, all file
functions would be apr_file_* ?
I'm -0 on that, but some targeted renames (like the one below) would be a
Good Thing.
Cheers,
-g
On Thu, Nov 30, 2000 at 04:03:50PM
Given the mapping you list below, are you considering a tighter
formalization of the namespaces *within* APR? For example, all file
functions would be apr_file_* ?
I'm -0 on that, but some targeted renames (like the one below) would be a
Good Thing.
Cheers,
-g
On Thu, Nov 30, 2000 at 04:03:50PM
The purpose behind this, is to allow people to specify a list of symbols
that they would like re-named before we release an APR beta. I feel very
strongly that once we release a library, we can't just change symbol names
at will. We want to keep the symbols as static as possible, to allow as
man
91 matches
Mail list logo
