Last changes before pushing 0.2.0


During the last time, I was working on a couple of features that we
thought they should be for 0.2.0.

Some of these features were actually fixing flaws in the design.

The point is that they are not many, but it changes lot of code, and
some of the API.

As it is a big change affecting both core and plugins (267 files
changed, 33743 insertions, 34387 deletions), I'm pasting here the git
branch where the changes are stored.

I'll summarize the changes done:

* [BIG] Refactor Grilo sources: so far, there were two types of sources:
media sources and metadata sources. The first group provides content
(Jamendo, youtube, local, ...), and the second complements the
information obtained from the first (like album arts from Lastfm).

The idea is that plugins (which are dynamic libraries loaded by core)
provide one or more of those sources. But if you take a look in code,
the implemention is broken in design (though it works).

So in this work, basically I've simplified things an now there is only
one type of source: GrlSource. This source can act as a media source and
metadata source.

How the already existent sources are migrated for the new system?
Basically, all the methods in GrlMediaSource/GrlMetadataSource are in
GrlSource. The main difference is about the metadata() function: it has
been merged with resolve() function.

The key for resolve() to behave like old metadata() or like resolve() in
metadata source is the may_resolve() function. If source doesn't provide
one, the default behaviour is that application asks for a key that the
source solves, and the media comes from the same source, then it can
solve it. Plugin developer can re-implement this method so for instance
it can solve keys with content coming from other sources.

Within this refactor, I've added a new class, GrlPlugin, which basically
aggregates the sources. So now there is API to handle both plugins and

* [BIG] Improve the full resolution algorithm: this makes reference to
the algorithm that allows cooperation between different sources; what to
do when application asks for a key that is not solved by the source.

The current algorithm has some limitations: if several metadata sources
provide the same key, only one will be selected, even if it can't
resolve the key later. If the selected source needs to know other keys,
these new keys must be solved by the source we are browsing/searching.

I've tried to solve both limitations, trying to keep also the efficiency
of the whole system (not doing more requests to sources than strictly
necessary). So now, if several sources provide the same key, the one
with most priority is selected, but if it at the end can't solve the
key, the next one is selected, until they key is solved or no source can
solve it. Also, if the source asks for other keys as requirement, these
keys don't need to be provided by the media source, but can be from
other sources too. The core is in charge of chaining all the resolutions
needed to solve the keys requested by the application.

* [MINOR] Rename GrlPluginRegistry to GrlRegistry: besides reducing the
typing :), nowadays GrlPluginRegistry does not only register plugins,
but sources and metadata keys. So it seems logical to rename it to
"registry" (as in GStreamer). To avoid misunderstandings in the name of
functions, I've renamed a few of them (like grl_registry_load() to

* [MINOR] Put all the sources in the same place: as now we only have
"sources" and not metadata/media sources, I've moved everything to the
same place, like the old days.

What's the plan? Do the release of 0.2.0 during next week. And help
people to migrate their code from 0.1.x to new 0.2.0. Specifically, I'll
work on a patch for Totem. 

The goal is to have grilo 0.2.0 in GNOME 3.6.

This first version won't include the XML source factory I wrote, as I
need to adapt it to the new system (basically I need to merge both media
and metadata factories in just one).

I've tried to keep this email short, so for any question, just send an
email and/or contact through IRC.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]