httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <ra...@Covalent.NET>
Subject Re: Compromise
Date Wed, 08 Apr 1998 16:12:42 GMT
I support Brian's suggestion 100% here. We need to recognize what we
can accomplish and what is unreasonable. The more major rework has
always been a 2.0 target. Let's keep it that way.

Brian Behlendorf <> writes:
> Let's generalize this further.
> There are *two distinct problems* that it seems the apx_ advocates are
> trying to solve at the same time.  Let's solve one and then figure out
> whether and how to solve the other.
> The first problem is symbol hiding - renaming everything to ap_
> accomplishes that.  This is a good thing; I think we have all come to our
> senses and seen that HIDE is an incorrect long-term solution to the
> namespace collision problem. It was a quick hack that could get the job
> done, if it weren't for the added complexity it gives.   
> The second problem is whether we should mark private symbols and api
> symbols differently.  Much heat and fire there.  The bad news is that it's
> going to take us a lot of energy and time to decide what's in the API and
> what's not.  This is not a good thing to do when you're trying to get 1.3
> *done*.  This I think was Marc's main concern, and is certainly my concern.
>  The good news is there's no reason you can't take the time to gradually
> shift private functions over to apx_, given that there's consensus this is
> a good thing to do and agreement on which symbols to do it with.  The only
> people who are hurt by this are those who use private functions in modules,
> which shouldn't be happening anyways.  Granted without an API document no
> one can really say what's off-limits, but trying to wait on 1.3 until an
> API doc is produced defining this is going to guarantee we stay in
> beta-limbo indefinitely.
> Let's do the renaming to ap_, and release 1.3b6, and soon after 1.3.0.  I
> think trying to solve the second problem is admirable, but simply
> overwhelming at this point.  Let's be realistic about what we can
> accomplish.  At the same time I think work on the API document and renaming
> of private functions is worth pursuing, as I do think the decisions we make
> now will stay with us for 2.0.  Note that I don't believe we need a
> distinction between ap_ for things like "ap_cpystrn" and ap_ for API
> functions.
> I believe the current votes in STATUS reflect this possible chain of events.
> I don't think we should rename existing ap_ functions, and I don't think we
> should give all unmarked symbols something other than ap_.  
> 	Brian
> At 08:44 PM 4/7/98 -0400, Jim Jagielski wrote:
> >How does this sound... First of all, we decide whether to do the Great
> >Renaming or not... Marc's got a good point.
> >
> >Secondly, let's rename the current ap_ functions to something
> >else, like apx_. Now, all the functions we need to hide be prefixed
> >by ap_. During this, we take a look at those functions and "decide"
> >if that's OK... If they are obviously NOT API functions, then we
> >don't name them ap_, if we're not sure, we name 'em ap_ just in case.
> >Sooooo functions with ap_ may or may not be API functions, but those
> >with other prefixes definately ain't. This at least somewhat defines
> >the API by "throwing out" those functions that need to be renamed
> >but are obviously not API, although it doesn't do it completely.
> >
> >Is that at least a starting point?
> >
> >And for those keeping track, yep, it's me again coming up with
> >compromises... For a prick, I seem to be the only one who does.
> >Maybe, to me, the words "group effort" are more than just words...
> >-- 
> >===========================================================================
> >   Jim Jagielski   |||   |||
> >            "That's no ordinary rabbit... that's the most foul,
> >            cruel and bad-tempered rodent you ever laid eyes on"
> >
> >
> --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
> "Optimism is a strategy for making               
> a better future." - Noam Chomsky              

View raw message