Re: Gack! Weirdo DAV bug.

On Fri, Nov 16, 2001 at 03:30:39PM -0800, Ryan Bloom wrote:
> On Friday 16 November 2001 11:18 am, cmpilato@collab.net wrote:
> > Ryan Bloom <rbb@covalent.net> writes:
>...
> > > Option 3. :-) We have APIs to allow you to check the dynamically
> > > registered methods.
> >
> > I'd already thought about this. But the methods hash is just
> > NAME->number mapping. What would this gain us? We already have both
> > the name and the number in the request structure. Maybe I'm missing
> > something (I hope).
>
> You misunderstood me. We already have the APIs to do this. The same way
> that you compare against M_INVALID, you could actually check against
> REPORT directly.

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.

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 :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org