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

["Juan A. Suarez Romero" <jasuarez igalia com>]

On Mon, 2010-09-06 at 12:39 +0200, Iago Toral Quiroga wrote:
> 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.


I wrote a patch to bring this feature to Grilo. It should be somewhere
in the mailing list. It is not that I'm proud of it, but it could be
used as a starting point.

> 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.

Yes. I forgot to send this previously.

Moreover, I've chosen this feature as my next work to do in Grilo (after
finalizing all stuff about rygel-grilo and totem's plugin).

> 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.
> 

I had this idea on my personal TODO. But after Miguel implemented a Qt
application that was using Grilo as backend, I totally forgot about it.

Also, I read some time ago about a project to generate Qt objects from
GObject introspection. If this compiler really works, it would be worth
to take a loot at it.


> 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.
> 


FYI, I wrote down in my notebook some notes about approach this feature.
In fact I was considering both ideas together, as the former leaded me
to the later.

The notes I had were inspired by Gstreamer work, and IIRC, I discussed
(or mentioned at least) them to Victor.

I didn't mention them before because I wanted to be sure that actually
they're worth to do.



	J.A.