Re: [Rhythmbox-devel] Rhythmbox And Vala - Questions:

[Sean McNamara <smcnam gmail com>]

Hi,

I currently maintain an out-of-tree GPLv2 Vala plugin for Rhythmbox,
called rbpitch: http://tiyukquellmalz.org/cgit/rbpitch . Clearly the
questions in your email (and correct responses to them) are of great
interest to me, so I will offer my thoughts, and then watch the list
carefully in case anyone has a different opinion :)

On Mon, Jun 28, 2010 at 4:41 AM, Daniel Hams <daniel hams gmail com> wrote:
> Hello List,
>
> I'm new to this so please excuse me if this isn't the right forum to
> discuss this. And sorry if some of these are stupid questions.
>
> I've been working on automating the creation of Rhythmbox Vala plugin
> bindings following some work Michal Hruby did, and have some general
> questions about Rhythmbox's expectations and future intentions vis a vis
> Vala.
>
> Vala bindings bug with script:
> https://bugzilla.gnome.org/show_bug.cgi?id=621246
>
> Now, putting aside the state of the current bindings script for a
> moment:
>
> (1) Does Rhythmbox ever intend to ship .vapi files that will allow
> compilation of out-of-tree plugins?
>
> Basically this would mean publishing a .pc, header files and the
> relevant .vapi files in the appropriate system locations

Supporting out-of-tree native plugins (i.e., plugins that link against
the C libraries) has been something I have wanted of Rhythmbox for a
long time. Out-of-tree plugins have been possible in Python for a
while because you just have to write interpreted code against the
plugin API as exposed via the Python bindings.

Last I checked, this is starting to materialize in git; Jonathan has
been doing a lot of work on supporting this.

Obviously, the first step is to enable out-of-tree C plugins. Once
that setup is working, then it makes sense to create Vala bindings.

I last investigated the status of out of tree plugin support around
May 25, and my conclusion was that it is close, but not ready for
plugin developers to dig right in. Things may have changed since then.

IMHO, the most difficult part of creating any out-of-tree bindings for
Rhythmbox is that there's no explicit plugin API (or, there isn't, to
my knowledge). In-tree plugins written in C effectively have full run
of the town, able to link against any part of Rhythmbox and call any
internal functions. Exposing the full internals of Rhythmbox in
bindings of any sort (even Vala bindings) is ugly, and probably not
desired.

There is a distinction between an explicit plugin interface and a
stable one. It can be explicit *and* stable, or just explicit. Later
in my message I discuss the viability of an explicit interface that is
not stable; right now I am about to discuss an explicit *and* stable
interface. If we create a stable plugin interface, it runs the risk of
being (1) too inflexible to be useful; or (2) not a realistic view of
the internals, which would necessitate nasty hacks to maintain
compatibility with the stable plugin ABI as the core and DB evolve.

One downside of maintaining an explicit plugin interface that is not
stable (i.e., changes with every release) is that you have to keep
updating the bindings. BUT! If your scripts for auto-generating the
bindings work well, that won't be a problem at all, will it?

>
> (2) Maintenance of the bindings - currently the Vala tools for
> automating the .vapi file generation (vapigen) are a little weak on
> automation - for example you must explicitly hide artefacts - which
> makes maintaining a plugin API rather a pain. What is needed for
> Rhythmbox to consider bindings generation maintainable?
>
> Assuming we can get some patches to the Vala tools to "autohide" any
> newly added artefacts - would this make automation of binding generation
> satisfactory?
>
> I'm guessing that the bindings regeneration (if automated) should be
> re-done based on a dependency with the librhythmbox-core library - if
> it's newer than some timestamp of the .vapi creation, we re-generate the
> bindings.

The way I see it, hiding artifacts that technically _could be_ bound
is not really productive. It makes the .vapi shorter, but you might
exclude some functionality that someone needs. These last two
statements are based on a world where we do *not* have an explicit
plugin interface; that is, the only thing explicitly plugin-related is
RBPlugin; the rest of the core is "implicitly" usable by plugins, in
theory.

There are really two ways that I think this could be done relatively
sanely: either with an explicit plugin interface (doesn't necessarily
have to be "stable" or "frozen"), or by binding all of RB's internals
indiscriminately at every release (the "implicit" approach).

Is there a half-way horse? Could you reliably and regularly maintain
the subset of rb-core functions that are needed by plugins, while
excluding all functions that are never needed by plugins? Even if this
is possible to puzzle out, I think it should be done by the core devs,
not by people just trying to bind the API. And then this subset should
be exposed as a separate library at link-time, as the explicit plugin
interface.

To elaborate: my favored method would be to keep the linkage of
plugins completely separate from the core. So you would have a shared
library, librhythmbox-plugins (or something like that), which contains
RBPlugin and related classes, plus a carefully determined exposure of
the rb-core internals. If necessary, we could bump the plugin API
version on every stable rhythmbox release, to make it as easy as a
"call through" for librhythmbox-plugin to implement its API. This
would, at least, alleviate the need for maintainers to support an old
public interface when the core has changed between releases. This
would also mean plugins need to be recompiled for a specific RB
version, but that is mostly true of the status quo as well, isn't it?
It's all open source, so it shouldn't be a problem :)

This would have the very significant benefit of providing a cleanly
separated design layer for plugins, which would encourage all the
non-C bindings (Java, Python, Mono, Vala, etc) to implement the same
well-defined set of functions (i.e., every public function in
librhythmbox-plugins). The frozenness or stability of the plugin
API/ABI could be determined by the core devs as they evaluate the long
term viability of the interfaces vis a vis planned changes in the
current major version. A long term goal for the project might be to
make a major release, then freeze the plugin API/ABI for an entire
major release. If that's too inflexible, then you could enforce
source-level compatibility, so all plugins that work with version n-1
can be recompiled without any source changes for version n. The latter
is a weaker level of frozenness, but provides a good compromise
between stable interfaces and allowing the core to evolve.

>
> (3) If auto-generation of the .vapi files is not considered feasible -
> what mechanism will be used to create / maintain them?

The *current* .vapi in git is an amalgamation of the original Vala
sample plugin's bundled .vapi (which its original committer generated
by hand), plus a bunch of added functions that I included to support
rbpitch. As you can tell by reading the .vapi, it is very incomplete,
and even the included bindings may not be 100% correct. This is
unfortunately a case of open source laziness, where I did just enough
hacking on the bindings to get them to work with software I was
developing to consume them. Now, I'm glad I didn't bind the entire
rb-core, because your automatic generation probably does a better job
of that than I ever could.

Auto-generation sounds like the way forward, as far as Vala bindings
in general. As long as everything we need is a GObject, introspection
should reliably give us what we need. If vapigen is not working for
you yet, I say give it time, and wait until it is generally useful
without many hacks. It is still in heavy development, so it may not be
an ideal tool until ptitjes or others improve it.

HTH,

Sean

>
> I'm sure the devs have given this more thought than I have, and for the
> moment I'm a little unsure what's the best way to proceed.
>
> Cheers,
>
> Dan
>
>
> _______________________________________________
> rhythmbox-devel mailing list
> rhythmbox-devel gnome org
> http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
>