apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@apache.org>
Subject Re: APR_TMP_DIRECTORY
Date Sun, 08 Dec 2002 22:09:27 GMT

> > 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.

We already have the function that returns the filehandle.  We are
specifically talking about adding the function that returns the filename.

> > 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?

Sorry, this section of my message should have been deleted.  My first
thought was that this is how you would get the apr_file_unique() function,
but as I said above, that support shouldn't be added to the library
anyway.

> > 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.

Huh?????  The API that we are discussing _has_ two functions for this.
One to get the filename and one to get the directory name.  What we are
talking about here is how you deal with a default compiled-in path versus
the one from the environment variable.  The solution that has been
proposed is a flag that is passed in.  But that flag is only going to have
an affect on Unix systems.  I would much rather just use logic like:

/* Add more if statemets for other platforms */
if (getenv("TEMP")) {
    return getenv("TEMP")
}
if (getenv("TEMPDIR")) {
    return getenv("TEMPDIR")
}
return PATH_TMP

This allows the system administrator to override the platform default.
What it removes is the ability to get the default value of PATH_TMP if the
administrator has overridden it.

Ryan


Mime
View raw message