httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bh...@gensym.com (Ben Hyde)
Subject re: vetoing hide.h
Date Tue, 31 Mar 1998 10:29:52 GMT
I'm very sad by the turn of events in the hide.h area.

This problem seem to have four threads:
  - Confusion about goals.
  - API design issues.
  - Process issues.
  - A tradeoff between core/module developers

- Goals

I, as a module author, need a solution to a problem.
  1. external symbol overlap.
  2. My customers don't have C compilers, particularly
     on NT.
  3. I don't want to require my customers to come to
     me for fresh Apache versions, though I will let
     them.
  4. I want dynamic linking on all platforms where
     I can get it.
     
- API Design Issues.

We all know that the Apache API is a lite hearted
design.  I see that is a symptom of it's success.
I've seen that in all young successful applications.  So,
when I saw it I was pleased rather than shocked.  Nailing
that lite heart down will be bloody hard work, it
it can make Apache more successful.

Hide.h has _NOTHING_ at all to do with API design.  It
is engineering, dirty oily, manly engineering to work
around the tedious 1960 technology we all love so much.

Why do people think this has anything to do with API
design?   First because of a mistake in naming
the rewrites.  ap_foo? apapi_foo? these imply these
are part of some exported API.  Second because 
"external symbol" sounds so much like "exported interface."

The rewrite name is entirely arbitrary!  The
choice of what to rewrite them to should:
  1. be good for those it effects (i.e. those that
     debug),
  2. not confuse people into thinking that this is
     about API design,
  3. increase the chance nieve viewers guess what's
     going on here.
If rule 3 was your goal then hide_foo might be a good
choice.  Since rule 1 is most important to me i'd
pick "fffoo" so I can type two letters with my strongest
fingers.  Rule 2 is why ap_ api_ or apapi_ are all 
BAD choices.

- Process Issues

It is clear that some amount of time must now be spent
revisiting this issue, since people feel blindsided.

I think the process here has been just fine, but that's
because I paid close attention through out the entire
process.  If one wander's away (as I have recently) then
you return only to discover things have happened and
since you didn't get to think thru the reasons, but
only get forced to swallow the "done deed",
well you get's pissed.

For example if your already pissed because you think
this was slipped in by some mad cowboy programmers that
avoided public review; and then you find that your
tags file doesn't work anymore you get more than pissed.

If on the otherhand you suffered thru the dozens of
messages about the topic and you watched the solution
evolve from one place in the design space to another;
then when this happens you try to remain bemused.
Your revise your tags generator and hack into
meta dot and go on.

But please recall that this change resolves real
problems that module writers have with how amazingly
STUPID 1960's linkers and languages are.  The linker
is the enemy here not the module authors or those
of use who think HIDE should be hardwired.

It is also wishful thinking that once you get a
competent developer to volunteer to do a project that
the project won't evolve in synch with his esthetics.
That's good.  It gets labor buy in, volunteers wander
off if you piss on their work.

The Apache Group is suffering from self destructive
behavior demonstrated by this example.  Ralf does
three very nice peices of work. (configure, shared
modules, and hide.h) If I had bought that work in the
open market it would have cost me easily 50 thousand
dollars.  His pay?  Buckets of negative feedback on
two them - so far.

The most defining moments in this project was when
the Ralf volunteered and when Ken switched the default
to yes.  The first event resulted in a cleaner bigger
mechinism than I originally asked for, but I'm happy I
got something - very happy!

The second, changing the default this is what is
pissing people off.  It was discussed before it
happened, but that's really not the problem.  The
problem?  As members of the group get back in synch,
often days and days after the change they discover
that they they can't debug and that meta-dot doesn't
work anymore.

People get go ballistic when they feel blindsided.
You can't convince a person he hasn't been blindsided.

It is sad that the best way to get the Apache Group to
focus on an issue is to veto something.  Possible a
"ah? wait a minute" or "please backup and discusss"
vote would be a good idea.

It is clear that some amount of time should now be
spent revisiting this issue, since people feel
blindsided.

- Core v.s. Module developers.

This issue, is the hardest one.  Because until we have
all tried living with the default as YES for a while
we can not actually know if it is tolerable.  I've
been living in this mode for a few weeks now and I
still find it only sightly grating.  I REALLY REALLY
want this functionality.

It's a rock and a hard place.  

We don't have a shared development environment - for
example we don't have a single set of tooks to build
tags files.  We don't all use the same editor.  How it
grates in differing environments will vary.

Since the default was switched to YES only two weeks
ago we have to wait before everybody comes in synch,
and sadly those that come in synch latter are more likely
to feel blindsided.

It's disconcerting to find people saying "I find it
too abrasive to put up with -- so make it go away."
What I hear: "My suffering is apparent to me, I don't
care about module authors having to build custom
versions of Apache, all I want is my pain to stop."
That maybe right or selfish I can't tell!

Both parties have to speak up about how bad the pain
really is going to be.

  - ben hyde

"Change?  We fear change!"  -- Beeves & Butthead








Mime
View raw message