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.h...@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 > _______________________________________________ rhythmbox-devel mailing list rhythmbox-devel@gnome.org http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
