Privacy Rewrite GSoC Project

[Sadrul Habib Chowdhury]

* Will Thompson had this to say on [20 Jun 2009, 23:33:26 +0100]:
[snip]
> 
> > 4. Privacy Public API:
> > 
> > (We will have a global PurplePrivacyState, or states can be set
> > separately for each account (account->account_privacy_type))
> > 
> >     * purple_privacy_state_set_global(...,PurplePrivacyState
> >       global_state,...)
> >     * purple_privacy_state_set_account(...,PurpleConnection *,
> >       PurplePrivacyState state,...)
> >     * purple_privacy_list_add(...,PurplePrivacyListType tp,
> >       PurplePrivacyListAddedCb cb,...)
> >     * purple_privacy_list_remove(...,PurplePrivacyListType tp,
> >       PurplePrivacyListRemovedCb cb,...)
> > 
> >     UI can register Cb that would be called on removing/adding a contact
> >     to a list, specifying error with error type if any ( if list
> >     modification fails asynchronously with the server, as stated by
> >     Will). Similarly callback will be implemented for every function
> >     that interacts with the server and might result in an error. 
> 
> Presumably p_p_list_add and p_p_list_remove() are meant to have contact
> ID arguments?
> 
> And I think these functions suggest that there should be
> PurplePrivacyList GObjects, which the prpl constructs and has a list of,
> which have attributes explaining what they are and what they mean. Then
> you'd have purple_privacy_list_add (PPL *self, const gchar *id, PPLACb
> cb, gpointer user_data, GDestroyNotify user_data_unref), which seems
> like a cleaner API to me than calling methods on the
> account/connection/prpl.

I was going to suggest using the account for such calls, instead of the
connectcion, so that the setting remains consistent across disconnects.
But I think I like what Will is suggesting more.

> Indeed, if libpurple is faking privacy lists that the prpl doesn't
> support, it can have its own set of supplementary list objects and react
> accordingly. I think it'll make the
> 
> >     *
> >       purple_privacy_allow_message(...,PurpleConnection *, const char *,...)
> >     *
> >       purple_privacy_allow_presence(...,PurpleConnection *, const char
> >       *,...)
> >     *
> >       purple_privacy_allow_both(...,PurpleConnection *, const char *,...)
> >     *
> >       purple_privacy_deny_message(...,PurpleConnection *, const char *,...)
> >     *
> >       purple_privacy_deny_presence(...,PurpleConnection *, const char *,...)
> >     *
> >       purple_privacy_deny_both(...,PurpleConnection *, const char *,...)
> 
> So assuming protocol support, these functions would just call the right
> thing on the prpl's privacy lists, and fall back to libpurple's fake
> ones, right? I think it'll make the API clearer if the functionality is
> properly layered: prpls give you lists you can poke, and an
> allow-all/whitelist/block-all etc. property which accepts only the
> values which are actually supported. Then, libpurple can have support
> code for UIs that want to pretend that all protocols are the same.
> 
> Given a couple more methods, like:
> 
>   const gchar * const *
>   purple_privacy_list_get_members (PurplePrivacyList *);
> 
>   gboolean
>   purple_privacy_list_contains (PurplePrivacyList *, const gchar *);
> 
> I don't see why another 'plist' API would be needed alongside this.

I agree with this too. It would be best if there aren't too many
PurplePrivacy prefixed structs/enums ... we don't need another
PurpleStatus look-alike!

Sadrul