"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 16:43:40 2002