[libpurple] Privacy API questions.

[Ethan Blanton]

Stephen spake unto us the following wisdom:
> 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 .
>>
>> 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. =)

It's disappointingly boring, actually.  ;-)  Basically, we got it Way
Wrong for 2.0, but fixing it requires ripping the old interface out
and building a new -- which means we break backward compatability with
anything compiled against libpurple 2.  Therefore, this is a change
which has to wait for the 3.0 release, and since that release isn't
yet imminent, it's not been a huge priority.  However, Sulabh did make
a lot of progress toward getting this ready during last summer's
Google Summer of Code.

>> 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?

Well ... a lot of such things have been pushed off because of the
simple fact that we know the privacy API is Bad and needs a lot of
effort.  However, we're gearing up to release 2.7.0, for which new API
can be added, and it does make sense to wrap this function up with
accessors, rather than having the user poke at it directly from
external to libpurple.  I'd accept a patch to make that change.  (I
probably won't get to it before 2.7.0 is released, I don't know if
someone else might.)

>> 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?

Right now it's on hold, so it's a great time for an extra pair of
hands to get involved.  Sulabh is very busy until summer, and I'm ...
just "busy".  ;-)   If you're interested in spending some time on
this, we should get Sulabh's hit on where things stand and whether he
has any particular plans already laid out, and then I think we can dig
right in.

Other developers can step in if they feel this isn't the case, but I
doubt we'll see a 3.0 release (which is required for this API to go
"gold") before next Fall, or even after.  Quite a bit of effort is
required to wrap up the 3.0 efforts already under way, and we
certainly don't want to jerk the codebase out from under any Summer of
Code students we might have during the summer.

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: 481 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20100408/3612539f/attachment.sig>