[Adium-devl] msn done right and switchboard timeout error

[Felipe Contreras]

Hi everyone,

In the process of re-factoring msn-pecan I stumbled upon the
switchboard timeout error, and it seems it's a wrongly reported error.

In order to send a message many things need to happen in the
background which apparently are transparent to the user. If there's no
connection established then a new connection is created, a
switchboard, then the invitation is queued (CAL), and a timeout for
this transaction is set (60 seconds).

Then, the connection begins, DNS resolve, switchboard authentication,
then the invitation (CAL), and finally the invitation acceptance. If
this process takes more than 60 seconds, a switchboard error is
raised, the whole thing is canceled, and the queued messages are
reported back to the user as failed because of a 'switchboard timeout
error'.

This works most of the time, but perhaps some operations need more
time in certain circumstances. Raising an error after 60 seconds is
not ideal. Increasing the timeout is just avoiding the real issue.

Pidgin has a patronizing policy; the user should not see the details
of what's happening behind curtains. While this in surface sounds like
a good approach; the truth is that issues happen, and when they do,
the user has no idea about what went wrong.

I believe a closer representation to what's happening can relief
frustration of the users. For example: if you send a message it
doesn't mean the message went through, it might take a while before
the message is received on the other side, if that happens at all.
Instead, it's possible to notify the user of what's happening: the
message is sent, but not yet received (gray), when the message is
received, the color changes to black, if it fails, it changes to red.
There are many other possibilities.

A similar thing happens with invitations to join a conversation.
Participants aren't immediately available, it takes a while before
they join. This can be represented on the UI as well.

But for now I want to focus on the switchboard timeout error, as it
seems it's a rather annoying issue for many people, many probably in
slow/crappy connections.

Experience has told me that changing things in libpurple is painfully
slow, so I personally would rather avoid that approach as much as
possible.

Adium already circumvents some issues in libpurple with custom
solutions, like msn_set_friendly_name, it would be possible to do
something similar with the status of message transactions by using
custom conversation messages marked with the PURPLE_MESSAGE_INVISIBLE
flag. That way the protocol plugin can then communicate to the Adium
UI directly what's happening: message received, message failed.

There are many alternatives: resend the message automatically, send
the message offline in certain errors, etc.

While this approach isn't ideal, it has potential as a first approach
to solve the issue properly, and can be further refined.

IMO blatantly displaying an error each time the message takes more
time than expected to be received is not ok.

Best regards.

-- 
Felipe Contreras