[libpurple] Privacy API questions.

[Ethan Blanton]

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.

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

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 477 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20100407/a2ba1c9b/attachment.sig>