> > 2) Why are we using a hash instead of a table? If this is all string
> > based, I believe a table will be much easier to deal with, plus we can
> > iterate through a table.
>
> It was initially a table. I asked for it to be a hash. The hash is faster
> and (yes) we can iterate through it. The mgmt/status data will not be purely
> string-based; the hash allows us to put integers, substructures, etc, into
> the hash table. A plain table cannot do that.
>
> (consider some module implementing counters of some kind; nicer to just pass
> integers rather than having to convert them to strings all the time; and
> substructures just couldn't be done)
How are you going to know what type it is? If mod_dav puts an integer
into the table, how is mod_status going to know to treat it as an integer
instead of as a string? Please don't say it just has to know, because
that means that this model isn't flexible at all, and I seriously dislike
that.
> > 3) Why is this a RUN_FIRST instead of a RUN_ALL?
>
> If the mgmt function runs the hooks and askes for "apache.dav.*", then
> mod_dav can satisfy the hook and terminate the scan.
How is this going to help mod_status? If it asks for "*", then it will
not get everything, and AFAICT, it won't be able to get everything, unless
we put a special hack into all of the hooks to have them return DECLINED
sometimes, even though they returned data. IMHO, this should be a
RUN_ALL, because otherwise you aren't going to get all the information you
want.
Ryan
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
