[libpurple] Privacy API questions.

[Stephen]

On 10-04-07 1:21 PM, Ethan Blanton wrote:
> Cc'ing over to devel@; please direct further replies to devel@ and
> trim support at .
>
> Stephen spake unto us the following wisdom:
>> I am relatively new in the realm of using libpurple, particularly in an
>> application that is not Pidgin nor Finch.  Recently I've been developing
>> some functionality to display blocked users in my own application, and
>> have been getting some peculiar results.  Thus far it smells like
>> there's a bug afoot in libpurple, but I figured I'd share these results
>> and ask a few questions before submitting a bug report.
>
> Well, it is and it isn't a bug.  :-)  It's a bug in that the privacy
> API really, really stinks.  It's not a bug in that it's the way it's
> "supposed" to work.

I bet[/hope] there's some sort of interesting tale as to why the privacy 
API has seen so little love over the years compared to the other areas 
of libpurple. =)

> There is a much improved but not-yet-merged privacy API written by
> Sulabh Mahajan for the 2009 Summer of Code.  It is available in our
> Monotone repository (directions for retrieving monotone sources are on
> developer.pidgin.im; the branch name is
> im.pidgin.soc.2009.privacy_rewrite).  It is targeted for inclusion
> when libpurple 3 is released (which has no target release date yet).
>
>> Libpurple uses a per-account member, 'perm_deny', to determine what
>> logic is used to determine if a buddy is 'blocked' (the meaning of
>> which, as I understand it, being highly protocol-dependent).  Thus, a
>> call to purple_privacy_check() on an account/buddyname pair should yield
>> FALSE if the buddy is blocked, and TRUE otherwise.  Furthermore,
>> callbacks to the privacy ui-ops are made when an account is signed in to
>> indicate which buddies are on the deny/permit lists for the account.
>>
>> However, the part that concerns me is that 'perm_deny' is being set to
>> PURPLE_PRIVACY_ALLOW_ALL upon account creation in purple_account_new(),
>> and this value is not changed unless either purple_privacy_allow() or
>> purple_privacy_deny() are called explicitly.  Therefore, any attempts to
>> check a buddy's blocked status via purple_privacy_check() happily
>> returns TRUE despite the permit/deny lists.  (I realize that the data
>> written to 'blist.xml' stores the 'perm_deny' value and the permit/block
>> lists, but using this saved data across sessions is not an option in my
>> case.)  Am I expected to be setting 'perm_deny' directly?
>
> As a UI, yes, you should be setting perm_deny to achieve the effect
> you want.  Our privacy management situation is unfortunate both for
> the user and the application developer.

Ah ha, that appears to have done the trick.  I would have jumped on this 
conclusion much earlier if there had of been some sort of public 
purple_privacy_set/get_permdeny_mode() accessor.  Any chance of 
including something like this, or are you planning on just waiting until 
you merge the rewrite?

> If you want to spend some time working with Sulabh and I to get the
> privacy rewrite code merged, that would be great.  ;-)

I'll pull the branch, have a look-see, and get back to you.  How are you 
two coordinating the effort?

 >
> Ethan
>

Thanks for the help!

Cheers,

   Stephen