[libpurple] Privacy API questions.
stephen at enflick.com
Fri Apr 9 13:10:46 EDT 2010
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.)
>>> 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.
More information about the Devel