On Friday 16 November 2001 06:49 pm, Greg Stein wrote:
> The current logic is basically:
>
> if (method_number != M_GET)
> return do_get();
>
> if (method_number != M_PROPFIND)
> return do_propfind();
>
> if (method_number != M_INVALID)
> return DECLINED;
>
> if (strcmp(method_name, "REPORT") == 0)
> return do_report();
>
> if (strcmp(method_name, "MERGE") == 0)
> return do_merge();
>
>
> We use the M_INVALID to shortcut a bunch of strcmp() operations on the
> method name. Switching that logic over to use the APIs is not going to save
> us much (if anything!) over the strcmp(). For each method, we'd have to
> call into the API to say "is it <this> one?" or "is it <that> one?"
>
> I'm going to have to look into this whole method registration thing. I saw
> it go in, but never bothered looking too closely. It didn't seem like it
> was going to monkey with the method number stored in the request. Eek.
The point was to allow modules to be able to associate a number with a
method that the core server didn't know anything about. In order to do that,
we did need to change the number.
> Dunno that the method stuff must change. At a minimum, mod_dav can just
> pre-register everything and keep the numbers around for use in the above
> logic. But I still want to get a look at the stuff and see what's there.
> I've got some particular experience with extended methods :-)
That was the original idea. Modules would register the method at startup,
and compare against that number, which is what the API's do.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:48 2006