apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@apache.org>
Subject Re: [time to move on I guess] APR_TMP_DIRECTORY
Date Wed, 11 Dec 2002 07:36:33 GMT
Thanks Brane... this was very well stated.

Bill

At 01:32 AM 12/11/2002, =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
>Dirk-Willem van Gulik wrote:
>
>>On 9 Dec 2002 cmpilato@collab.net wrote:
>>  
>>
>>>This *is* a portability question.
>>>    
>>>
>>
>>Well this is the crux- I think that this going further than abstracting
>>what the OS offer; but trying to put a layer on what a specific machine
>>offers or a specific operations environment.
>>
>>  
>>
>>>It *is* inside the domain of the portability layer.  It *does* belong in
>>>APR.
>>>    
>>>
>>
>>Therefore it it is my strong opinion that this is outside the domain of
>>portability and therefore should not be part of APR.
>>
>>Anything which does more than abstracting the pure OS but touches on an
>>instance of it I see as bad.
>>
>
>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 Čibej   <brane@xbc.nu>   http://www.xbc.nu/brane/


Mime
View raw message