Re: Grilo Config suggestion

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

On Sun, 2012-06-24 at 09:47 +0200, Roland Peffer wrote:
> Hi,

Hi, Roland.

> 
> As I see some plugins need some some config keys set (e.g. YouTube),
> or some config keys may be set optionally (e.g. filesystem).
> 
> 
> But if I am not wrong there is no way in the current API to discover
> what keys are needed, except to read in the code or documentation.
> This prevents to add a new plugin to an existing app without having
> hard coded knowledge in the app about the plugin.

Yes, you're right: there is no API for discovering the needed
configuration keys at this moment.

> 
> 
> Wouldn't it be better to add the individual config keys as GObject
> properties in the GRIO Plugins? The the available properties ( Like
> User, password etc.) could then  be discovered by
> g_object_class_list_properties.
> 

Thanks for the suggestion. This would need to change how we load and
present the sources to applications.

Note that before loading a source, you need to set up previously the
required configuration keys.... but you don't have yet the source
gobject.

Following a similar approach, we could also have a function that given a
source ID, it would return a list of GParamSpecs describing the
available options for that source.

Still, there are other issues to solve: defining which parameters are
compulsory and what others are optional, default values, and so on.

Another important point is that right now, we aren't distinguishing
between the config keys designed for users, and those designed for
applications.

Let me explain. There are keys that are suitable to be set up by the
users: username, password, or "mp3 quality" can be very well keys that
could be presented to users so they can set up or select the proper
value among a list. Others, like API key or secret token, are more
designed to be handle by the application developer who is using Grilo,
and not settle by user. At least, the former group should be
"introspectable" through the API, as you suggests. Not sure about the
later.

In any case, I agree with you we should have some kind of API to handle
this.

	J.A.