Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3E41809A.9030506@xbc.nu>
Date: Wed, 05 Feb 2003 22:22:34 +0100
From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@xbc.nu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.3a) Gecko/20021212
MIME-Version: 1.0
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
CC: dev@apr.apache.org
Subject: Re: Proposal: new filepath API for search paths
References: <5.2.0.9.2.20030205141915.03326cf0@pop3.rowe-clan.net>
In-Reply-To: <5.2.0.9.2.20030205141915.03326cf0@pop3.rowe-clan.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

William A. Rowe, Jr. wrote:

>++1 if we can go with
>
>APR_DECLARE(apr_status_t) apr_filepath_list_split(
>    apr_array_header_t **pathelts, const char *liststr, apr_pool_t *p);
>
>APR_DECLARE(apr_status_t) apr_filepath_list_merge(
>    char **liststr, apr_array_header_t *pathelts, apr_pool_t *p);
>

I could definitely do that.

>Let's drop the 'env' concept - this is really useful overall.
>
>And please be careful to strip quotes from around elements, and add
>quotes (or on unix, backslash escape) the seperator element (e.g. colon
>or semicolon.)
>
Sure. I think we already have code that can do that, so I might want to
do a bit of refactoring.

>Sure the default docs can illustrate the typical
>
>  apr_filepath_list_split(patharr, getenv("PATH"), p);
>
>but I think we want to stay away from overloading both getenv and split
>list facilities into a single function.  It makes the API less useful :-)
>
This is where it stops working. On Windows, at least on NT-class
systems, you really do want to use the wide char functions to read the
environment and convert the result to UTF-8, otherwise we're not safe in
the presence of characters that can't be represented in the current
locale. I don't want to lose that capability, after all the trouble we
(you?) went to in the other I/O functions.

apr_filepath_getenv, maybe? (Put it in the apr_filepath namespace
because the value it returns is suitable for input into other apr_file*
functions.)

>Oh, you might plan for a flags element for options like APR_FILEPATH_NATIVE
>where we could even do colon, forward slashed paths by default and follow
>the platform convention when APR_FILEPATH_NATIVE is passed ;-)
>
Bah. We have apr_filepath_merge; there's no need to duplicate that
functionality, is there?


-- 
Brane Čibej   <brane@xbc.nu>   http://www.xbc.nu/brane/