apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: [time to move on I guess] APR_TMP_DIRECTORY
Date Fri, 13 Dec 2002 00:05:16 GMT
I'm with OtherBill: well said.

Do we have some code for this? Can we just get it checked in already? We've
got enough +1 votes for the new feature, and I haven't seen any vetoes on
the implementation of the feature, so let's just do the code...


On Wed, Dec 11, 2002 at 08:32:22AM +0100, Branko Cibej wrote:
> 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 Cibej   <brane@xbc.nu>   http://www.xbc.nu/brane/

Greg Stein, http://www.lyra.org/

View raw message