httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: Compromise
Date Wed, 08 Apr 1998 12:56:12 GMT
I concede... It's obvious that one is listening any more. The fact that
people voted on doing the great renaming while at the same time as
the assumption was that different functions would have different
prefixes no longer seems the point. The idea that I was trying to
make the source clearer for people _writing_ Apache and Apache
modules again seems to be ignored... We'll "do it later" and then
when "later" comes up, we decide "Nope, can't touch it, no time"
and so it stays the way it is. The real fact of the matter is
that nothing further will be done after 1.3b6 is released or
1.3.0 for that matter. 1.3.0 will be out with a shelf life of
_several_ months before 2.0 is even a glint in our eyes, and it
will have a nebulous and fuzzy API with private and API functions
having similar prefixes... Imagine the confusion if instead of
the BSD kernel having prefixes like tcp_ and udp_ and in_ it just
had kernel_ to protect namespace problems.

Anyway, that's it... that's my point of view, my opinion and my
reasons for this.

Why try to "create" order where none exists? It's a lost cause
and isn't appreciated in the slightest.

+1

Brian Behlendorf wrote:
> 
> 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   |||   jim@jaguNET.com   |||   http://www.jaguNET.com/
> >            "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                         brian@apache.org
> a better future." - Noam Chomsky                        brian@hyperreal.org
> 


-- 
===========================================================================
   Jim Jagielski   |||   jim@jaguNET.com   |||   http://www.jaguNET.com/
            "That's no ordinary rabbit... that's the most foul,
            cruel and bad-tempered rodent you ever laid eyes on"

Mime
View raw message