httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <man...@io.com>
Subject Re: Context types in APR.
Date Fri, 07 May 1999 19:28:05 GMT
BTW, I'm wary of this whole context idea, but Ken is slowly convincing
me.

On Fri, May 07, 1999 at 01:06:17PM -0400, Ben Hyde wrote:
> No?  It would seem to me that you only need to pass a pool
> to those functions that create objects for the API.  For example
> 
>     obj = apr_obj_create(p, ...);
> 
> Operations that return fresh data structures should always take
> an explicit pool since the caller should decided what pool they
> belong in.

The main problem here is that there might be APR functions that take
no APR-created arguments. I didn't believe this was even possible
until Ken mentioned the canonical_filename stuff. This is definitely a
portability layer piece, and if demonical_filename retains its current
form, then it will take a string and return a string. How do we
support such an operation unless we pass in a pool/context?

There are answers of course. One is to make sure you *always* operate
on APR-created objects. In the case of demonical_filename, create
apr_string_t and do all our string operations through it. Qt does
this, and I don't like it.

Another answer is to handle files like Java does, which is to create a
Filename object (called File in Java) which is created from the string
of the filename. Then, demonical_filename would operate on this
Filename object, and so would all the APR file I/O routines. Is this
an acceptable solution for every case that resembles
demonical_filename? I personally don't mind it, but I'm sure others
will scream loudly.

-- 
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"Don't. You're too young to experience that much pain." -- Cmdr. Susan
  Ivanova, Babylon 5

Mime
View raw message