apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@apache.org>
Subject Re: [time to move on I guess] APR_TMP_DIRECTORY
Date Fri, 13 Dec 2002 00:14:27 GMT
On Thu, 12 Dec 2002, Greg Stein wrote:

> 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...

++1.  Whoever writes the code, please remember to add some tests for it.
:-)

Ryan

>
> 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/
>


Mime
View raw message