apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@xbc.nu>
Subject Re: [time to move on I guess] APR_TMP_DIRECTORY
Date Wed, 11 Dec 2002 07:32:22 GMT
Dirk-Willem van Gulik wrote:

>On 9 Dec 2002 cmpilato@collab.net wrote:
>>This *is* a portability question.
>Well this is the crux- I think that this going further than abstracting
>what the OS offer; but trying to put a layer on what a specific machine
>offers or a specific operations environment.
>>It *is* inside the domain of the portability layer.  It *does* belong in
>Therefore it it is my strong opinion that this is outside the domain of
>portability and therefore should not be part of APR.
>Anything which does more than abstracting the pure OS but touches on an
>instance of it I see as bad.

I'm getting the feeling that you don't understand what people are
saying. Most OSes I know have the notion of a (configurable) temporary
directory. For the purpose of brevity, I'll only mention two families:
On Unix, you have the standard $TMPDIR,/var/tmp,/tmp search sequence. On
Windows, it's %TEMP%,%TMP%,%SystemRoot%\TEMP. Windows also has a
GetTempPath() function, that returns a user- or app-specific temporary
directory name. On Unix, _all_ three locations can be tailored for your
application, either by setting the environment variable, or by locking
the app into a chroot jail and mounting /tmp or /var/tmp appropriately.
On Windows the path can be set per-program.

What we'd like to see in APR is not something above and beyond what the
underlying OS already provides; only a portable interface to those
facilities. There's a very strong argument in favour of putting this
into APR -- we can make sure that our implementation behaves correctly
on each target OS, which is something you can't expect of homegrown
solutions, as you've been saying yourself.

If you're worried about apps not behaving nicely -- why, if APR doesn't
provide the APIs, people will just go ahead and use the non-portable OS
functions, or worse, think up their own. From a sysadmin's point of
view, there will be absolutely _no_ difference; bad programmers will
behave antisocially whether or not APR provides the portability layer.

The ony one who loses not having this feature in APR is the responsible
programmer who would _like_ to use a portable API, but can't. Now that
ain't nice.

Brane ─îibej   <brane@xbc.nu>   http://www.xbc.nu/brane/

View raw message