Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 72384 invoked by uid 500); 5 Dec 2002 17:41:16 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 72373 invoked from network); 5 Dec 2002 17:41:16 -0000 From: cmpilato@collab.net Sender: cmpilato@collab.net To: Aaron Bannert Cc: APR Dev List Subject: Re: APR_TMP_DIRECTORY References: Reply-To: cmpilato@collab.net Date: 05 Dec 2002 11:38:20 -0600 In-Reply-To: Message-ID: Lines: 15 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Aaron Bannert writes: > I don't like the idea of having environment variables drive things > like this. Temp directories are a great way to get programs to > write files wherever you want. I'd much rather have a function where > the global tempdir can be set and then retrieved later by > apr_get_temp_dir(). The nice thing about this is it doesn't incur > any processing overhead when apr_get_temp_dir() is called, and can > let apps like httpd create their own config directive for setting > the preferred tempdir. Maybe I'm missing something obvious, but if all that exists are functions for setting and getting a tempdir, what is APR providing except a storage place for a program's code? I mean, that ignores the whole point of having it in APR -- the *portability* aspect.