apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <di...@webweaving.org>
Date Sat, 07 Dec 2002 13:57:24 GMT

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

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 :-)


View raw message