[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [ghudson@MIT.EDU: Re: svn commit: rev 3110 - trunk/subversion/include]

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-09-03 16:22:53 CEST

"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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.