On Sat, 7 Dec 2002, Thom May wrote:
> How is the *portable* creation of temporary files a "function of dubious > use"? Surely our mandate is portability. I'd argue that functionality like > this should absolutely be in APR. The portability layer is to facilitate porting; not to hide things which are to be controlled on a per application per platform basis once in operations. Suppose you have 5 applications all using APR -but due to shoddy programming they are conflicting in their use of this 'temp dir' - or once makes a very differnt type of use of hte temp dir than the other; i.e. more write's than reads, or small files versus big files. You want to encourage the app. programmer to define settings/controls on application level; not on the hidden apr level. > And what about a cross platform application, that may not need to be under > direct app control but will need to be able to work correctly on Windows and > Unix and whatever else. If an app *needs* specific usage, then let them use > it, but in the common case, why force every app to reinvent the wheel for > something that 100% should be in a portability library? In my opinion there is barely common use of the tempnam() and certainly no common use of the tempdir; I've seen app's use it for gigabytes of caching.. On platforms like solaris your /tmp is directly in swap space; on other platforms it is on an expensive sytem disk, yet on other platforms it has special reboot semantics. So I argue that putting these sort if functions in, just because you can, is simply poluting your portability layer. On a higher level; I guess the argument is; when are you done; when you cannot think of functions to add; or when you are done removing functions and brought it back to it's core. I very much admire the quality of libc and the area's it carefully does NOT try to walk into :-) Dw
