Re: API change?

[Randy Terbush <ra...@zyzzyva.com>]

> I wouldn't call this an API *change* so much as an *enhancement*;
> the key thing is to try to make it useful for other things as well.
> For instance, if there's a mechanism for modules to go find other
> modules, it would be nice for other modules to be able to inform
> mod_includes of new include commands they might implement, to
> inform mod_log_config of new log file formatting directives they
> might support, and so forth.
> 
> rst

Giving modules the ability to communicate features seriously complicates
this enhancement.

It seems it would require us to assign 'classes' to modules.
How do we deal with precedence of duplicate commands?

Adding a uchar to the module structure would accomplish what
I propose, and would probably be needed for an init routine
that would accomplish what RST is suggesting.

Ideas?

Re: API change?

[ra...@madhaus.utcs.utoronto.ca]

> It seems it would require us to assign 'classes' to modules.
> How do we deal with precedence of duplicate commands?

I think the classes are already there in a sense.  The module structure
fields for handler, filename trans, check user id, check auth, check access,
type checker, fixups, and logger are the groups.  One module may fit into
a couple of groups.  From this it should be possible to generate a listing
which shows the mime type and the modules which would operate on this
mime type in each of the 8 groups.  If multiple modules have an entry for
the same group for a particular mime type then it is listed in the order
that the modules are in.  It would be a nice tool for checking that you
have your modules linked in the correct order and that you have the modules 
that you want.  The modules themselves should be able to probe this 
listing to check for any conflicts/dependencies as well.

-Rasmus