Privacy Rewrite GSoC Project

[Will Thompson]

Ahoy,

I wasn't suggesting having a *second* list of everyone alongside the
buddy list for storing privacy; I was suggesting getting and setting
attributes of buddies on the buddy list as the API for manipulating the
protocols' internal lists. :) But I think in retrospect you're probably
right to present the UI with API to manipulate the privacy lists directly.

Sulabh Mahajan wrote:
> typedef struct _PurplePrivacyState
> {
>         PrivacyStateType privacytype;
>         PrivacyStateOf privacyof;
>         gboolean privacy_state_local; /* defines whether this features is local only/faked or implemented on server */
>         gboolean privacy_state_needs_local_storage; /* to keep track of which states require storage of list locally */
> } PurplePrivacyState;

> define_supported_privacy_states() is a function that necessarily be
implemented by each protocol. It registers a list of states of type
PurplePrivacyState that a protocol supports. It can also be replaced by
a linked list of elements of type PurplePrivacyState.

On XMPP, you can only determine after you connect to a server what kind
of blocking/filtering extensions it supports.

I don't think prpls should know anything about faked privacy features.
To my mind, that belongs in helper code in libpurple.


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

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.

>     typedef enum _PurplePrivacyItemType
>     {
>             PRIVACY_ITEM_TYPE_MESSAGE =1,
>             PRIVACY_ITEM_TYPE_CHAT,
>             PRIVACY_ITEM_TYPE_NOTIFICATION,
>             PRIVACY_ITEM_TYPE_FT,
>             ...,
>             ...
>     } PurplePrivacyItemType;

Just a nitpick: I don't like the naming here. I don't know what a
'privacy item' is; these sound like modes of communication to me, with
nothing directly to do with privacy.

Sorry for the rather fragmented reply,
-- 
Will

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20090620/7c0b0b70/attachment.pgp>