Brane,
> >The idea to have platform independent API for different platforms is
> great.
> >But, that makes me think that if APR could provide Java interfaces to APR,
> >that could bring a big benefit to Java Developers who are struggling with
> >creating own implementation of common things like ne
Alex G. wrote:
Hello,
I just joined the list and am not sure if this topic has been already
discussed.
The idea to have platform independent API for different platforms is great.
But, that makes me think that if APR could provide Java interfaces to APR,
that could bring a big benefit to Java
Kenneth Falck wrote:
The simplest fix to this would look something like this (file_io/unix/
filepath.c):
APR_DECLARE(apr_status_t) apr_filepath_encoding(int *style,
apr_pool_t *p)
{
#ifdef DARWIN
*style = APR_FILEPATH_ENCODING_UTF8;
#else
*style = APR_FILEPATH_ENCODING_LOCALE;
#endi
On Mon, Aug 22, 2005 at 01:56:27PM +0100, Joe Orton wrote:
> > Also while we are at it, do you remember why 8000 was chosen as the size
> > of the buffer (I remember why it wasn't 8K, but I wonder why not 2k or
> > 4k?) is it because it perfectly fits the memory page? but how do you
> > ensure t
On Fri, Aug 19, 2005 at 01:56:30PM -0700, Stas Bekman wrote:
> Joe Orton wrote:
> >On Fri, Aug 19, 2005 at 12:07:37AM -0700, Stas Bekman wrote:
> >>We do care, because we write a throttling filter for the smtp module, so
> >>we want to slow down the spammers, reading 8K defeats the purpose of the
On Monday 22 August 2005 13:12, Joe Orton wrote:
> > Erm, because ENOTIMPL is an error, whereas this noop isn't?
>
> Now I'm confused; all apr_status_t values other than 0 are "errors" by
> definition. If you mean, "because the caller can be taught to treat
> APR_NOOP as non-fatal", well, sure;
On Mon, Aug 22, 2005 at 01:00:13PM +0100, Nick Kew wrote:
> On Monday 22 August 2005 12:13, Joe Orton wrote:
>
> > > OK, I guess what we really want here is an additional return code
> > > APR_NOOP. NOTIMPL is inappropriate, and you've raised an objection to
> > > SUCCESS.
> >
> > Why is ENOTIMPL
On Monday 22 August 2005 12:13, Joe Orton wrote:
> > OK, I guess what we really want here is an additional return code
> > APR_NOOP. NOTIMPL is inappropriate, and you've raised an objection to
> > SUCCESS.
>
> Why is ENOTIMPL inappropriate?
Erm, because ENOTIMPL is an error, whereas this noop isn
On Monday 22 August 2005 12:09, Jeff Trawick wrote:
> maybe do the APR_SUCCESS no-op flavor and give the app a way to query
> if certain features are enabled; so an app could fail at startup if
> there is no threads support but it doesn't want to run with such a
> build of APR; querying feature se
On Mon, Aug 22, 2005 at 11:43:12AM +0100, Nick Kew wrote:
> On Saturday 20 August 2005 23:33, Jeff Trawick wrote:
> > On 8/20/05, Nick Kew <[EMAIL PROTECTED]> wrote:
> > > Jeff Trawick wrote:
> > > > If APR always provides such APIs and acts like they work, what is to
> > > > signal to a threaded A
On 8/22/05, Nick Kew <[EMAIL PROTECTED]> wrote:
> On Saturday 20 August 2005 23:33, Jeff Trawick wrote:
> > On 8/20/05, Nick Kew <[EMAIL PROTECTED]> wrote:
> > > Jeff Trawick wrote:
> > > > If APR always provides such APIs and acts like they work, what is to
> > > > signal to a threaded APR app tha
On Saturday 20 August 2005 23:33, Jeff Trawick wrote:
> On 8/20/05, Nick Kew <[EMAIL PROTECTED]> wrote:
> > Jeff Trawick wrote:
> > > If APR always provides such APIs and acts like they work, what is to
> > > signal to a threaded APR app that they are picking up a non-threaded
> > > libapr?
> >
> >
On Sun, Aug 21, 2005 at 04:36:51PM +0200, Erik Huelsmann wrote:
> On 8/20/05, Joe Orton <[EMAIL PROTECTED]> wrote:
>
> > > I promissed Karl Fogel a reproduction recipe, but didn't succeed in
> > > creating one. OTOH, I think it's clear the line needs changing...
> >
> > I've committed this with a
13 matches
Mail list logo
