Re: [PATCH 00/18] Flickr's personal source (grilo plugins part)

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

On Mon, 2010-07-12 at 09:28 +0200, Iago Toral wrote:
> > 
> > a) Do nothing. Each application needs to take care of how to get the token in
> > they want to use it. In case of grilo-test-ui, user must provide a valid token.
> > 
> > b) Just add the functions/code in grilo-test-ui. Other applications would need
> > to address the problem as they want.
> > 
> > c) Creating a separated project with this functions. It's a bit weird having a
> > small library with a very reduced subset of Flickr's API, and tightly tuned to
> > be used with Grilo.
> > 
> > d) Add the functions to the plugin .so file. A bit weird, as for instance
> > grilo-test-ui will be loading dynamically the module, as well as it will
> > dynamically linked against the library.
> > 
> > e) Add them to a small and separated library in flickr plugin. This is the
> > option I choosed. Besides the flickr-plugin .so library, a
> > libgriloflickrauth.so library is created and installed in standard place,
> > containing these set of functions. When packaging in a distro, the best choice
> > would to create a separated package from the plugin itself containing this
> > small library, so users can install it or not if required.
> > 
> > What is your opinion?
> 
> I have a feeling that Grilo's work should start when the user has provided a 
> valid configuration token, otherwise we are providing APIs that are plugin specific 
> and I think that is at odds with the target of the project. In this case this 
> process seems to be too flickr specific to be included in grilo in any way.

Grilo's work is already starting with user providing an optional valid
token.

All functions regarding getting this token are out of grilo's scope.
They're included in grilo-flickr plugin to take advantage of shared
code. But still they are in different .h files, and heavily separated
from the plugin itself.


> Taking that into account I'd say that my preference is either a) or b), that 
> is, the responsibility of obtaining a valid token is for the user or the application, 
> and Grilo is not involved there in any way.

As I said, applications can get the token as they want. It is not
mandatory to use this helper library.

> 
> c) Not sure why that should be tuned for Grilo... but again, I think we should 
> not take any responsibility here. IMHO, it is ok to give app developers the 
> responsibility to get a valid token and authorize it.

I added it as an option which I don't like either.
> 
> d) is pretty weird.

Agree.

> 
> e) is another option although I have a weird feeling about it (packaging a -dev 
> package from a plugin that is specific to use one feature of that plugin goes 
> a bit against the generic purpose of grilo and feels like we are addressing 
> something in grilo that is totally out of its scope).

My feeling is that it is out of grilo's scope, because it is not in the
core. Yes, it is included in one of the plugins, but I wouldn't say that
plugins are part of the "core" of Grilo. Rather, I would say that they
are part of standard or official set of plugins.

In any case, I was very careful about separating this library from the
rest of plugins. Unfortunately, as plugins are all in the same
repository and not one plugin per repository, maybe one can feel that
this helper is part of all plugins; but it wasn't the case.

	J.A.