[Bug 44331] Gabble plugin API symbols should be factored out to a separate library

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=44331

--- Comment #7 from Olli Salli <ollisal at gmail.com> 2012-01-04 13:54:26 PST ---
> So I was wondering, is this a fundamental incompatibility of GSimpleAsyncResult
> with Windows .dlls, or are we just using it wrong? Anybody has a lead on
> somebody who would be a guru in GIO and Windows?

Answering myself in a separate comment because otherwise this is likely TL; DR.
However, THIS comment has my .02€ on how to solve it, the above one is just
rationale and a description of the practical problem we're having. SO PLEASE
READ AT LEAST THIS ONE!!

My opinion is that we're actually using GAsyncResult wrong here. The gabble
plugin interface has some odd hidden assumptions to fulfill. Its
(UNDOCUMENTED!) GabblePluginCreateSidecarImpl create_sidecar function receives
a callback and user_data parameter. It must somehow magically know that they
should be used as a callback for a GSimpleAsyncResult, with the source tag set
to a gabble symbol.

Isn't the general idiom in GIO that the function which creates the GASR, sets
itself as the source tag? This is not currently the case, as the plugin
implementations create it but set it to a symbol from gabble. (again, not
possible on Windows).

This would be fixed most straightforwardly by starting to create the GASR in
gabble, in the gabble_plugin_create_sidecar wrapper function, or even before in
gabble_plugin_loader_create_sidecar (and changing the expected source tag in
that case). Then, we'd pass this GASR through the plugin API, and have the
plugin just call _complete() on it... This would work even in Windows, because
the GASR is created and hence the source tag set in the same linker output file
as is the check for the source tag done.

But actually, wouldn't even more idiomatic be having the plugin interface
contain both a create_sidecar virtual function returning a GSimpleAsyncResult,
and a create_sidecar_finish virtual function which digs out the resulting
GabblePlugin from the GASR? Yeah this is two virtual funcs instead of one, and
the second one is 95% the same for all plugins, but it's just a few lines
anyway, and this way would be much cleaner IMO.

Here are some solution alternatives, but the question is, can we make such
changes - that is, are external parties depending on the Gabble plugin API
staying backwards compatible?

Otherwise, we'll just need to admit that the source tags can't be sensible on
windows, and remove the asserts checking for them, or at least pass NULL to the
g_simple_async_result_is_valid call, in which case the source tag check is
skipped.

But we also need to make a mental note of not adding more stuff to the plugin
API where the plugin would need to create a GASR to be finish()ed by Gabble
code or the other way around. Or is there already other things like this?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.