apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Fogel <kfo...@newton.ch.collab.net>
Subject Re: [time to move on I guess] APR_TMP_DIRECTORY
Date Fri, 13 Dec 2002 04:38:33 GMT
Greg Stein <gstein@lyra.org> writes:
> 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...

It's just been waiting on Mike Pilato (or someone) having enough time
to implement it now, that's all.  No procedural holdups remain,
agreed.

-Karl, speaking for Mike, who is perfectly capable of speaking for
       himself, but it's me checking email right now, not Mike :-).




> 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