apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: [time to move on I guess] APR_TMP_DIRECTORY
Date Mon, 16 Dec 2002 11:59:13 GMT
Actually my memory is that we don't any form of agreement on how this should
be implemented or even what problem the discussion was trying to solve -
that's why I haven't written anything yet. I was all set to write the code
but the discussion and feeling expressed mean I won't now.

It'll be nice if we ever do it as it means that apache might build on beos
again :)


----- Original Message -----
From: "Greg Stein" <gstein@lyra.org>
To: <dev@apr.apache.org>
Sent: Friday, December 13, 2002 12:05 AM
Subject: Re: [time to move on I guess] APR_TMP_DIRECTORY

> I'm with OtherBill: well said.
> Do we have some code for this? Can we just get it checked in already?
> 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...
> Cheers,
> -g
> 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