[libpurple] Privacy API questions.
stephen at enflick.com
Thu Apr 8 10:37:05 EDT 2010
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?
Thanks for the help!
More information about the Devel