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 [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
