Re: Expectations for Grilo plugins that require passwords

[Iago Toral Quiroga <itoral igalia com>]

Hi,

I am not sold on this idea yet, I think it is a bit weird to handle
things this way.

So, this GrlData the user would receive is empty, except for that
password-protected-data metadata key... basically, users must know that
they have to check for this metadata when they receive GrlData objects
that do not contain the data they expected?. If we want to go this way
I'd rather return an error, I think it is a more convenient way to
inform the user about this special situation...

Iago

El jue, 01-09-2011 a las 17:33 +0200, Víctor M. Jáquez L. escribió:
> On Thu, Sep 01, 2011 at 06:10:03AM +0000, Iago Toral wrote:
> > 
> > FWIW, I think the same. My vote would be to put this signal in core.
> > 
> 
> Juan and I were talking about the issue a couple days ago. Juan proposed
> another option: add a new meta-data like PASSWORD-PROTECTED-DATA. So the
> source could stamp that to the GrlData that requires password in order to
> fetch it.
> 
> When the application receives a GrlData with that meta-data, it can react as
> it wishes.
> 
> With this model we will not lose the asynchronous mechanism, which is one the
> strengths of grilo. If we use a signal for each protected share, we would
> block the grilo's operation meanwhile the user decides what to do with it.
> 
> Also this approach is very little intrusive to the code in comparison with the
> signal one. 
> 
> Later on we could add a helper library, for handling password's dialogues or a
> fancy signaling mechanism.
> 
> vmjl
> _______________________________________________
> grilo-list mailing list
> grilo-list gnome org
> http://mail.gnome.org/mailman/listinfo/grilo-list
>