Hi,
I am running out of time at the moment, but I think at least for mod_dav it
makes more sense to have the ctx members, than have a userdata argument to
function, because mod_dav is really object oriented, only implemented in C.
So most of these structure are really objects (and that's what they become
in Perl).
I will provide you with some sample code as soon as I have a little free
time. (Hopefully later today or tomorrow moring)
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
-------------------------------------------------------------
----- Original Message -----
From: "Karl Fogel" <kfogel@newton.ch.collab.net>
To: "Gerald Richter - ecos gmbh" <richter@ecos.de>
Cc: "Greg Stein" <gstein@lyra.org>; <dev@subversion.tigris.org>
Sent: Tuesday, September 03, 2002 4:22 PM
Subject: Re: [ghudson@MIT.EDU: Re: svn commit: rev 3110 -
trunk/subversion/include]
> "Gerald Richter - ecos gmbh" <richter@ecos.de> writes:
> > > So could you maybe give a code example?
> >
> > Yes, of course!
>
> What I meant actually was literal C code, or pseudocode, showing what
> you are trying to do. I'm having trouble following your prose
> description -- it's written very clearly, but I think I must be subtly
> misinterpreting some of your terms, because I still don't see the need
> for a `void *ctx' inside the called library's struct.
>
> > 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.
>
> I meant something like this:
>
> typedef int (*foo_handler_t) (foo_t *foo, void *userdata);
>
> int read_foo_stream (foo_stream_t foo_stream,
> foo_handler_t handler,
> void *userdata);
>
> (In Subversion, we say "baton" instead of "userdata", if that helps).
>
> For example, you write a function of type foo_handler_t (mod_dav
> merely defines the type, but *you* define the function). Then you
> pass your handler and its userdata to read_foo_stream(), and the
> handler gets invoked on each foo object in the stream. The function
> read_foo_stream() is implemented by mod_dav, but the handler is
> implemented by you, and internally it casts `userdata' back to some
> struct type you defined, and accesses its closure-specific data inside
> there.
>
> So here's my question:
>
> Obviously, the `void *ctx' field inside a mod_dav (or Subversion)
> structure cannot be used by mod_dav (or Subversion) itself, since the
> field is opaque. Given that field is used only your functions anyway,
> why can't your need be equally satisfied by having mod_dav carry
> `userdata' arguments in the right places?
>
> If mod_dav doesn't pass userdata arguments where you need them, then
> let's patch it to do so, instead of patching it to have void *ctx
> members inside its own structures.
>
> (It may be that in order to carry the userdata to the right places,
> mod_dav must also store the pointer in some structures, but that's
> fine -- that's driven from the function interface level, and is just
> part of implementing the promised interface).
>
> > 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.
>
> Okay, these "some other functions" need to carry along a userdata
> parameter, then (?).
>
> But again, I feel there must be something I'm missing here, especially
> after reading your last sentence. If you can give a real code
> example, I may understand at last...
>
> Sorry if I'm being obtuse,
> -Karl
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 3 17:06:05 2002