On Sunday, December 8, 2002, at 11:02 AM, <[EMAIL PROTECTED]> 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
