Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Sun, 8 Dec 2002 13:45:07 -0800
Subject: Re: APR_TMP_DIRECTORY
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v548)
Cc: David Reid <dreid@jetnet.co.uk>, APR Dev List <dev@apr.apache.org>
To: <rbb@apache.org>
From: =?ISO-8859-1?Q?Wilfredo_S=E1nchez?= <wsanchez@wsanchez.net>
In-Reply-To: <Pine.LNX.4.33L2.0212081043420.10448-100000@vangogh.rkbloom.net>
Message-Id: <518FA010-0AF6-11D7-940A-000393A5892E@wsanchez.net>
Content-Transfer-Encoding: 7bit

On Sunday, December 8, 2002, at 11:02  AM, <rbb@apache.org> wrote:

> Can you just implement please?  There are three functions below, 
> between
> those three functions and the existing apr_file_mktemp(), we can do
> EVERYTHING that people are asking for.

   What the hell's the big rush?  We can talk and then build, or build 
and then clean up the mess, if any.  Both ways work eventually.

> The only thing I would change, is I would drop it to three functions by
> getting rid of apr_temp_get_unique.  That function can be accounted 
> for by
> passing NULL into apr_temp_get_filename for the directory.  Also, the
> apr_temp_get_unique really doesn't have anything to do with temporary
> files.  The PHP uniqid function just generates a unique string, APR
> doesn't need to implement that feature, because APR-util already has 
> UUID
> support, which is designed to generate unique strings.

  +1

> The way I see thing working is that the user would do the following to 
> get
> a filename in the system's temp directory:
>
> apr_temp_get_filename(apr_temp_get_directory(...), ".foo", pool);

   I think this should return a filehande, not a filename.  Or make it 
two functions.

> To get a filename without a directory, they would do:
>
> apr_temp_get_filename(NULL, ".foo", pool);

   OK, but what's the point of that?

> The ability to use a compiled in default path (PATH_TMP) is harder to 
> deal
> with, because most platforms don't have that concept.  I don't believe
> that it is a good idea to add flags that only really make sense on some
> platforms.  We are better off IMNSHO, just ignoring that case for now, 
> and
> force the app developer to handle it themselves by passing that macro 
> to
> apr_temp_get_filename.

   Um, yuck.  The whole point of apr_temp_get_directory() in David's API 
was to return that directory.

   You're talking about an equivalent to apr_temp_get_filename() which 
returns a directory instead of a file.  That's two different functions, 
which I suggested previously.

	-wsv