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

[Iago Toral <itoral igalia com>]

On Wed,  7 Jul 2010 18:19:55 +0200, "Juan A. Suarez Romero"
<jasuarez igalia com> wrote:
> And now, the small issue which I would like to hear opinions for.
> 
> Getting a valid token requires to invoke two Flickr's API functions, and
> showing an URL carefully designed. While doing this is not a very big issue, it
> is actually a pain in the ass, as requires to carefully write them, use
> signatures, and so on.
> 
> As most of these problems are already addressed in flickr's plugin itself, I
> decided to add a couple of functions to make the developer's life easier. This
> functions are used for instance in grilo-test-ui. But how to distribute these
> functions? Choices that come to my mind are:
> 
> 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.

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.

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.

d) is pretty weird.

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

Iago