IDEA: mmm... actually it is a bunch of ideas :)

[Iago Toral Quiroga <itoral igalia com>]

Hi all,

this is  a list of topics I would like to propose for discussion. I am
not actually supporting all of them, but I think they are all worth
sharing and discussing with others. I know that sending a separate mail
per item would make discussion easier, but there are quite many items in
this list so I decided to merge all of them in a single post. They are
not sorted by any particular order and there is a bit of everything in
terms of scope.

----- 8< ------ 8< ------ 8< ------ 8< ------

1.- Async plugin loading (actually, proposed by Eduardo some time ago).

Right now plugin loading is synchronous, async plugin loading would be
better.

2.- Vala bindings with GObject introspection

Not possible now, but we should have this in our roadmap I think. Right
now Victor is maintaining the bindings manually.

3.- Python plugins

I think it would be great offering the possibility to develop plugins
for Grilo in Python.

4.- Real upload API

we have some APIs for storing content (used in some plugins like
podcasts and bookmarks), but it is nothing serious, we need to try and
implement some serious services like Flikr or Youtube and adapt the APIs
accordingly.

5.- Check i18n needs (actually proposed by Víctor)

We have to think about i18n in Grilo.

6.- Code examples

I would like to have a good collection of source code examples
illustrating how to use Grilo. These would be in a separate directory in
the repository for people to look at.

7.- Multiple value metadata

Right now we only support single-valued metadata, that is, if some
resource has more than one artist or more than one thumbnail, we can
only provide one.

I think it is time to see how we could handle multiple-value, because
for some cases it is very interesting. Some examples are
  - GRL_METADATA_KEY_URL: Some services can provide various versions of
the media resource, in different formats. One example of this is
Youtube. We can't handle that now.
  - GRL_METADATA_KEY_THUMBAIL: Some services may provide various
thumbnails for the same resource, maybe in different sizes. Again, one
example of this is Youtube. We can't handle this at the moment.

And I am pretty sure there are more examples.

8.- Improve GRL_RESOLVE_FULL implementation

When I implemented it a left a few TODO/FIXME things about a couple of
things that could be improved.

9.- HACKING file

We should have that with the code standards, etc

10.- Cache

We should think about how Grilo can provide cache of the results, which
I think would make a lot of sense. This was brought up by somebody at
GUADEC btw.

11.- DeInit functions in plugins

We should probably review many of the plugins and provide proper deinit
functions for them.

12.- Plugin realoding features

Right now we cannot implement plugin reloading. We are using
G_DEFINE_TYPE macro, which in turn uses g_type_register_static which
prevents this feature, would be nice to look into that and look for
alternatives to this.

13.- Sorting

This was brought up in the mailing list some time ago and our conclusion
was that, at least for now, it is enough if we do not provide any means
for sorting the results and we rely on the plugin developer to do some
sorting that makes sense for each case.

I still think that, but when I think about the future I wonder if
sorting would be something we want to be more flexible about. Just to
bring the topic back to life and see what other developers think about
this.

14.- D-Bus APIs (actually proposed by Juan)

MediaServerSpec is a D-Bus API but it is pretty different from Grilo's
and it definitely does not allow third party developers to use all
Grilo's features through D-Bus. Juan mentioned once he would like to
have a D-Bus API for Grilo.

15.- Qt bindings

Some people mentioned this already. Grilo can be used already from Qt,
there is nothing special about it, but having specific bindings could
make it more friendly for Qt developers.

16.- Port/move plugins from other apps to Grilo (Totem, Rhythmbox, etc).

I guess this one does not need further explanation :)

17.- Extend the registry APIs with, at least:
  - Load a single plugin providing only its plugin-id.
  - Get a list of all loaded plugins (not sources).

18.- Reconsider redesigning the GrlMediaPlugin -> GrlMetadataSource ->
GrlMediaSource hierarchy

I think GrlMediaPlugin could probably be a separate class, to be
aggregated by GrlMetadataSource and GrlMediaSource instances rather than
something they inherit from (after all one is about plugins and the
other is about sources). I still think we would need an abstract class
for GrlMetadataSource and GrlMediaSource instances to inherit from
though.

19.- Configuration API.

I am referring here to configuring Grilo itself, not one of its plugins.
I think in the future some aspects of Grilo would accept configuration.
One example of this could be the caché implementation (if we go with
that).

Probably I am forgetting a lot of stuff, but I guess this is enough for
now.

----- 8< ------ 8< ------ 8< ------ 8< ------

Iago