> Hrm. Gerald, I'm a bit embarrassed to ask this, since clearly Greg
> Hudson understood your explanation, but confess I didn't understand
> it...
> So could you maybe give a code example?
Yes, of course!
> I'm still not clear
> how having void *ctx inside Subversion's (or mod_dav's) structure
> gives you access you couldn't get as efficiently with your own
> structure.
>
> In the example you gave (involving the dav_resource structure), I
> presume any callback that takes a dav_resource also takes its own void
> *userdata or something like that, so why wouldn't your ctx go there?
>
I cannot talk about subversion, I talk about mod_dav, because I knew it's
internals. I do it from my mind, so please forgive me if things not 100%
accurate, but I only want to explain my reasons for suggesting adding a ctx
member to Greg at when we meet at the OSCON.
As you know mod_dav delegates the work of actually accessing resources to
providers. Each provider is defined by a struct, which contains a set of
callbacks. On the other side we have structs like the dav_resource, which I
mentioned in my previous example. With the current design of mod_dav
(without ctx) I have two problems when I try to build the Perl API:
1.) I call get_resource and get a dav_resource structure. This structure is
an input parameter to some other functions, which go through mod_dav and
call at some point the provider. The dav_resource struct gets an Perl object
associated, now when mod_dav calls the provider (which is possible also in
Perl), we want to get the Perl object. If we have an ctx member in the
resource struct, that's an easy task. If not we need to go along and use a
hash for mapping, with all the problems I described in my last email. The
point here is, that while this is a sort of callback, there is no function
which takes a ctx argument to the callback.
2.) I need to keep state in my provider. By using the ctx member it's easy.
When I create a new provider I can go the way to wrap it in my own struct,
if I add my ctx member at the end, if I want to attach a Perl object to an
existing provider that doesn't work.
> In general, I guess my question is, why is the solution to add an
> inline field in existing structures, rather than to use an existing
> userdata closure (making a patch to add userdata if it doesn't exist,
> of course)?
>
Now I am not quite sure if I understand what you mean by "userdata closure",
if you mean passing an userdata function argument to the function that takes
the callback function as argument, then the answer is, that mod_dav
providers doesn't work in this simple way. You can't do it there.
Hope it's a little bit more clear, if not don't hesitate to ask again
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 3 16:12:04 2002