httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ras...@lerdorf.on.ca (Rasmus Lerdorf)
Subject Re: vetoing hide.h
Date Wed, 01 Apr 1998 03:04:51 GMT
> That is what makes it a short-term solution.  I understand the motivation
> and also why it can't be a configurable option.  But, I still consider
> the HIDE solution to be *worse* than the problem you are having.
> It's cool, it seems like a good idea at face value, but when I actually
> looked at the long-term effect it will have on trying to understand our
> (still no more documented than before) API, the result had to be a veto.
> We need to find a better way (and I will do so if nobody beats me to it).

Well, I suppose if you are not personally experiencing the problem then
the solution is definitely worse for you.  But for me, it isn't.  I spend
plenty of time debugging my module and stepping into Apache, but I can't
say that the HIDE stuff has slowed me down much.  I don't really
understand your argument.  The problem HIDE solves is one that hits end
users whereas the drawback is only experienced by people who know enough
to use a debugger and have enough initiative and motivation to venture
into the guts of Apache's code.  Surely HIDE is not going to confuse
people like this.  If HIDE is too complex for them, they have absolutely
no hope of ever understanding the bulk of Apache.  I don't see how you can
even compare these two situations and call one worse than the other.  I
suppose it comes down to who is more important; end-users or developers?  

I would certainly welcome an alternative as long as it addresses the
problem, but please don't just pull HIDE and release 1.3b6 without any
sort of solution.  I am having enough of a hard time making sure my module
builds with all the Apache releases as it is.

-Rasmus


Mime
View raw message