bot-sentry pidgin msn spam interaction

[deckrider]

On Thu, Jul 3, 2008 at 2:26 PM, deckrider <deckrider at gmail.com> wrote:
> On Mon, Jun 30, 2008 at 12:08 PM, Ka-Hing Cheung <khc at hxbc.us> wrote:
>> On Mon, 2008-06-30 at 06:57 -0600, deckrider wrote:
>>> Hello, I'm writing to ask some advice about the following bug:
>>>
>>> https://sourceforge.net/tracker/index.php?func=detail&aid=2002718&group_id=156021&atid=798112
>>>
>>> Is there a way to suppress these error messages so that they don't
>>> open windows (but not other messages that aren't a result of this
>>> plugin)?o
>>>
>>> Or is the recommendation in the bug the way to proceed (wait 5 seconds
>>> and then check if the user is on line before sending the challenge)?
>>>
>>> Or possibly some other alternative?
>>
>> You can't check if the buddy is online unless the buddy is in your buddy
>> list, right? If the buddy is in your buddy list, there's probably no
>> point in sending a challenge?
>>
>> I am not sure how best to solve this, libpurple does not have a way to
>> notify the caller when a prpl operation fails, so the prpl can only
>> write to the conversation when something goes wrong. Maybe trap the
>> conversation signals and hide it?
>
> Yes, that was what I thought, but it seems that the conversation
> doesn't exist at all.  Then because of the switchboard error, the msn
> protocol _creates_ the conversation and then writes to it.
>
> As I understand it (PLEASE correct me if I'm wrong here), _creating_
> the conversation is what opens the window.  And it bot-sentry's
> mission to block this initial opening of the window.
>
> It does appear that one can connect to writing-im-msg and block
> further text from being written to the window.  But by then it is
> pointless since the window would have already needlessly opened, thus
> disturbing the user.

I haven't seen a response to this, so I'm thinking I'm correct, that I
cannot suppress this message from my plugin.

Therefore I'd like to ask if a change to the msn protocol plugin might
be considered in this regard so that it won't open a new conversation
to report an error from a message sent automatically by a plugin that
couldn't get through when there is not already a conversation open.
There is a patch available in the above referenced bug report for
this.

I'm also open to other ways of doing this, since I may not be aware of
all the requirements surrounding this plugin.  If my patch falls
short, can we discuss please?

Thanks in advance.