Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43317249.6010002@rowe-clan.net>
Date: Wed, 21 Sep 2005 09:46:33 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720)
MIME-Version: 1.0
To: Joe Orton <jorton@redhat.com>
CC: dev@apr.apache.org
Subject: Re: [PATCH] apr_dso_load2() with flags support
References: <20050909110506.GA11389@redhat.com>
 <4321B40C.8050902@rowe-clan.net> <20050909164510.GA7930@redhat.com>
 <4321C28D.1060702@rowe-clan.net> <4331684A.1050803@rowe-clan.net>
 <20050921141820.GD10767@redhat.com>
In-Reply-To: <20050921141820.GD10767@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Joe Orton wrote:
> On Wed, Sep 21, 2005 at 09:03:54AM -0500, William Rowe wrote:
> 
>>Ping since the thread tied here, and Joe's looking for an answer...
> 
> Eh?  Everything you say below is reasonable.  But that doesn't help me 
> understand why you say the proposed API is "unportable" nor to resolve 
> your veto.  What question do you need anybody else to answer?
> 
> Again: can you propose an alternative apr_dso_open_ex() API so I can 
> understand your point?

What I'm saying is that you *must not* have any special platform 
knowledge to use apr_dso_open_ex().  Which means that picking from all
of the flags and mapping the dlopen API as 'our new apr_dso_open' isn't
the right solution.

Can you define a few problems you want to solve, and we will map them
to appropriate combinations of flags, and determine if they can be
1) supported, 2) ignored, 3) not implemented across our platforms?

Bill