httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: apache handlers (1)
Date Wed, 06 Aug 1997 09:13:18 GMT


On Mon, 4 Aug 1997, Alexei Kosut wrote:

> 1. This is not a new idea. I suggested it several months ago, and it is
>    part of the plan for 2.0 (which is held completely in the mind of a
>    couple developers. Just try and get at it! Hahahahaha!)

And it's different in each of our minds too.

> 2. Adding additional phases to the module record is backwards compatible
>    (it's not forwards compatible, but that's another matter). ANSI C is
>    smart enought to fill in the extra slots without complaining.

But it requires a recompile of the module... but in practice this is
required occasionally anyhow as the api mutates.

> 4. As near as I can tell, your patch does not provide the equivilent of
>    Dean's optimizations to eliminate NULL handlers.

Haven't looked closely, but in theory it can do this easily.  But you have
to dictate in the API that the register function can only be used during
the init_module phase.  This is a reasonable requirement in my opinion ... 
but I know others differ ... others that want to get rid of all phases! 

> 5. It does not provide a graceful mechanism for adding new phases to the
>    API, either. It would require new functions to be added for each of
>    those. IMHO, it's better to have a single callback register function
>    of which one argument is an enumeration (or set of #defines) that
>    specifies which phase you are registering for. This allows modules to
>    be compatible with older versions of Apache (see my earlier email on
>    specifies of this. I don't feel like going over it again right now).

Yeah I was going to mention this.  An enum would be better.

> 6. As Roy has repeatedly pointed out, if we do this, there are better
>    things we can do: Currently, handlers are only registered by content
>    type. It would be very handy if they were also registered by method,
>    and possibly other things. We'd need to sit down and either think of
>    all these things (unlikely), or set up the callback functions to be
>    extensible (more likely).

But handlers and the other (api) methods are slightly different beasts. 
Just slightly though. 

What is stopping a module from setting r->handler during, say, fixups ?
Something like this is a more general solution ... but not complete.

I think what Roy wants with (http) methods is a way of enforcing a few
pieces of the protocol.  Right now it's too easy for a handler to not
handle a certain method properly.  By making methods part of the
registration it forces the module writers to think about what they really
handle.  You can't do this with r->handler fixups because those override
all other handlers, whereas what you really want is a default that takes
effect if certain things are true. 

Dean


Mime
View raw message