Re: [Opensync-devel] osync_objtype_sink_get_userdata intentionally not exported?

[Luiz A. D. de L. <lui...@gm...>]

---
     Luiz Angelo Daros de Luca, Me.
            lui...@gm...


2011/6/6 Chris Frey <cd...@fo...>

> On Wed, Jun 01, 2011 at 02:09:25AM -0300, Luiz Angelo Daros de Luca wrote:
> > Maybe we are talking about different things. :-) The objformat is already
> > avaiable to who askes for it.
> > My suggestion is to do something like these:
> >
> > char *osync_objformat_print(OSyncObjFormat *format, const char *data,
> > unsigned int size, OSyncError **error) {
> >     (...)
> > +   return format->print_func(data, size, format->user_data, error);
> > -    return format->print_func(format, data, size, format->user_data,
> > error);
> > }
> >
> > And so on for all callbacks. plugin and sink does just like this. My ruby
> > wrapper can implement multiple objformats (and plugins) and I have, for
> each
> > callback type, only one C callback for all ruby objects. If I have
> > the format inside the callback, I can look for the ruby callback defined
> for
> > this format.
>
> Sorry for the delay.  I'm sure this is frustrating for you.  I hope you
> don't give up! :-)
>
>
Not yet :-) I was fighting with video encoders the last days... Opensync
looks like a sunny
day when looking at some  "... leading audio/video codec library"


> I have to be honest, that adding this argument, as a special case for
> wrapper code, just feels like the wrong move. :-)
>

It could be used for any format that wishes to share a callback
function. For example:

print_func(format, data, user_data) {
     print "Data from %s", get_name(format))
     print data
     if (get_name(format)=="file") {
         print user_data.filename;
     }
}


>
>  From a C perspective, this kind of data belongs in the user_data block.
> By including the format pointer in the user_data (which you need in order
> to register print_func), you have everything you need.
>

print_func was just an example. My real problem is that initialize, which
defines user_data,
is already a callback function and it has no arguments. I have unique C
callback, one for each type. Every format
"instance" shares the same callback in C world. This callback, with the help
of some data (user_data), retrieve the
ruby callback for this format "instance" and call it. However, initialize
does not have arguments but error. So
there is nowhere to retrieve the "data". It is a chiken'n'egg problem.

When initialize is called, I don't know which format is initialing. Remember
that this function is shared among all
ruby format objects that defined the initialize function. However, if it
was:

static void *osync_rubymodule_objformat_initialize(OSyncObjFormat
*format, OSyncError **error)

I could, based on format, retrieve the ruby callback, initialize user_data
and return it. Without format, I have no solution.

I can solve my problem only adding format to initialize arguments. However,
I suggest that all of callbacks should pass the struct that it is related.


> - Chris
>
>
>
> ------------------------------------------------------------------------------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe,
> secure and there when you need it. Discover what all the cheering's about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Opensync-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensync-devel
>