Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 5 Dec 2002 09:55:56 -0800
Subject: Re: APR_TMP_DIRECTORY
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
From: Aaron Bannert <aaron@clove.org>
To: APR Dev List <dev@apr.apache.org>
Content-Transfer-Encoding: 7bit
In-Reply-To: <m37keofjsj.fsf@localhost.localdomain>
Message-Id: <CDD0756E-087A-11D7-9902-000393B3C494@clove.org>


On Thursday, December 5, 2002, at 09:38  AM, cmpilato@collab.net wrote:

> Aaron Bannert <aaron@clove.org> writes:
>
>> I don't like the idea of having environment variables drive things
>> like this.  Temp directories are a great way to get programs to
>> write files wherever you want. I'd much rather have a function where
>> the global tempdir can be set and then retrieved later by
>> apr_get_temp_dir(). The nice thing about this is it doesn't incur
>> any processing overhead when apr_get_temp_dir() is called, and can
>> let apps like httpd create their own config directive for setting
>> the preferred tempdir.
>
> Maybe I'm missing something obvious, but if all that exists are
> functions for setting and getting a tempdir, what is APR providing
> except a storage place for a program's code?  I mean, that ignores the
> whole point of having it in APR -- the *portability* aspect.

APR could set sane defaults in autoconf, and the implementation might
vary per-platform (eg. Windows would use/cache the path returned from
the path function).

My main point here is that it is bad to use environment variables
for such things, and it's probably bad to have to run something
every time a temp dir is needed (like check permissions or search
a list of paths and stat() each one). I'd much rather see the apps
leave this decisions up to the users, for example, a simple config
directive in apache.

-aaron