[libpurple] Privacy API questions.

[Stephen]

On 10-04-08 11:01 AM, Ethan Blanton wrote:
> 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.)

Done.  #11656.


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

   Stephen