Privacy Rewrite GSoC Project

[Sulabh Mahajan]

On Mon, Jul 20, 2009 at 2:25 PM, Sascha Vogt <FunkyFish at gmx.net> wrote:

> Hi,
>
> Mark Doliner schrieb:
> > [snip]
> >
> > I'm strongly in favor of faking blocking messages for protocols that
> > don't support.  It's what most users expect.  I don't think it is
> > necessary to notify UIs when a message is blocked, but I don't object
> > to it.
> Well, one use case where such a notification would be of interest:
> In case a users wants to block all messages from users not in his list a
> plugin could notifiy about the *first* message. That way the user could
> check if that new contact is a valid one, or just spam. Subsequent
> messages could then be safely ignored.
> The Bot Sentry plugin may also use such a callback.
>

If we are notifying the UI's when a message is blocked, they must assume
that delivery of the blocked message is not guaranteed. Depending upon the
privacy state set by the user for a particular account, it might be faked
locally (ie server sends us the message, but we drop it locally) or
implemented at the server (we don't receive the message). In the former case
libpurple can provide the UI with the blocked message, but can't even know
that there was such an event in the latter case.

With no guarantee of being notified about a dropped message, would we really
want this feature.

Along with passing the blocked message in the callback, we can notify the UI
when the blocking is server side to make sure that UI knows when it won't be
receiving any notification about a message being blocked. But isn't that too
complicated for a simple feature.

If we have to forward the blocked message to the UI, how is it not different
from letting the UI drop the blocked messages instead of the privacy
subsytem at the libpurple.

-- Sulabh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20090722/a4ac9c34/attachment.html>