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 :) david ----- Original Message ----- From: "Greg Stein" <[EMAIL PROTECTED]> To: <[email protected]> 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? 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... > > 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 <[EMAIL PROTECTED]> http://www.xbc.nu/brane/ > > -- > Greg Stein, http://www.lyra.org/ >
