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? 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?
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)?
-K
"Gerald Richter" <richter@ecos.de> writes:
> My original request of this ctx field was for mod_dav, but the same
> arguments applies to svn too. I run into problems while I was writing a Perl
> API for mod_dav, so let me explain:
>
> As long as I create the struct this wrapping should work, but in case the
> struct is returned by mod_dav and I want to attach a Perl object that
> doesn't work anymore.
>
> For example in mod_dav the dav_get_resource function returns a dav_resource
> structure. I need this structure in many other calls, for example to
> retrieve properties. In Perl the dav_resource struct becomes an object. If I
> have the ctx pointer I can store a reference to this Perl object in the ctx
> member and anywhere I see this dav_resource struct (for example in some
> callback, that is called from mod_dav into Perl) I can get my Perl object.
> In this case I cannot use the a wrapper, because then I have to copy the
> dav_resource struct, which may lead to invalid pointers in parts of the
> other code.
>
> I hope this make things more clear, if not just ask again. If I am overseen
> something here and there is a better way to do these things I am happy to
> learn...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 2 21:06:20 2002