Bug 71306

MSN has the same issue. But I don't consider it a bug, I consider this the _wanted_ behaviour. You don't want to type a lengthy message to another user only to discover he or she has gone offline. What we *could* do is to add a message to the chat window with the warning that the user is offline and messages won't be received. Additionally we could leave the text area disabled in that case. That would also solve the inconsistency - we would just do the same with open chats.

Martijn

Come on...how often do people sit there typing up long messages on an IM?  And the odds of this happening accidentally while the other person has gone offline are infinitesimilly low.

> What we *could* do is to add a message to the chat window with the warning
> that the user is offline and messages won't be received.

I guess I wouldn't object too much to that.  As long as I could still send a message to the server, and get the server's error response.

> Additionally we could leave the text area disabled in that case.

Dear god no...that defeats the whole purpose of this request.  I don't think it's Kopete's job to tell me I can't send a message, I think it's the server's job.  Most other IM clients happen to agree.

Subject: Re: [Kopete-devel]  Kopete should not preemptively block me from sending messages to offline users, but give me a server error instead

On Sunday 28 December 2003 19:27, Casey Allen Shobe wrote:
> I don't think it's Kopete's job to tell me I can't send a message, I think
> it's the server's job.

? Que ?

Why on earth should one want that?

The only case I can think of are bugs in our heuristics, and those should be 
fixed in Kopete, they are not an excuse for attempting to send first.

You really want to shortwire the whole server round trip if you *know* that 
the request will fail anyway.

The issue is that our broken online status in Oscar erroneously makes 
connections that are actually valid impossible.

The other issue is (arguably) that we disallow chat window creation.

The first issue should be fixed at any rate, the second one can be discussed 
and we can probably reach some kind of compromise, but stupidly sending 
messages that are known to fail to the server anyway is downright stupid IMO. 
Actually, it even makes it harder to come up with decent error messages, 
because with the knowledge of a user being unreachable upfront you can make 
sure to write a descriptive error, whereas when relying on a server response 
you are completely dependent on a server giving an error in the first place 
for a protocol and on the error being unique enough to recognize the 
situation. Lastly, the parsing would be protocol dependent and thus not 
benefit from shared code and i18n strings in libkopete.

Subject: Re: [Kopete-devel]  Kopete should not preemptively block me from sending messages to offline users, but give me a server error instead

Sunday 28 December 2003 13:35
> Why on earth should one want that?

So I can see why my message failed.  Obviously I can't see the person online, 
but sometimes the server may clarify further, for instance differenciating 
between when the message couldn't be sent because the user was offline and 
when the message couldn't be sent because the user blocked the sender (I'm 
pretty sure AIM does this)...

> The issue is that our broken online status in Oscar erroneously makes
> connections that are actually valid impossible.

That is an issue, yes.

> The other issue is (arguably) that we disallow chat window creation.

That is a large part of this issue...

> Actually, it even makes it harder to come up with decent error messages,
> because with the knowledge of a user being unreachable upfront 
> you can make sure to write a descriptive error, whereas when relying on a
> server response you are completely dependent on a server giving an error in
> the first place for a protocol and on the error being unique enough to
> recognize the situation. Lastly, the parsing would be protocol dependent
> and thus not benefit from shared code and i18n strings in libkopete.

That's not true...

if ($errstr == 'ERROR_REMOTE_OFFLINE') {
	$error = i18n ('Message could not be delivered because the remote party is 
offline.');
} else if ($errstr == 'ERROR_REMOTE_BLOCKED') {
	$error = i18n ('Message could not be delivered because the remote party has 
blocked you.');
} else {
	$error = $errstr;
}
print $error;

Vertu s

Subject: Re: [Kopete-devel]  Kopete should not preemptively block me from sending messages to offline users, but give me a server error instead

On Sunday 28 December 2003 19:44, Casey Allen Shobe wrote:
> > Why on earth should one want that?
>
> So I can see why my message failed.  Obviously I can't see the person
> online, but sometimes the server may clarify further, for instance
> differenciating between when the message couldn't be sent because the user
> was offline and when the message couldn't be sent because the user blocked
> the sender (I'm pretty sure AIM does this)...

In that case Kopete could just as well send a dummy message (it wouldn't 
arrive anyway) to find out and report the reason straight away. No need to 
allow a user to type messages that won't arrive for that.

With MSN each chat has its own socket, so just opening a chat window already 
triggers the creation of such a socket and you would find out the reason 
straight away.

I don't think either of these belong here though. It makes a lot more sense to 
incorporate this information in the tooltip, e.g. by detecting this state if 
a tooltip is visible for more than a second and updating the tip once we know 
the result, perhaps also caching it.

IMO this is a typical example of requesting information from Kopete that in 
itself is a very valid wish in the wrong location from a 
usability/architecture POV.

> > Actually, it even makes it harder to come up with decent error messages,
> > because with the knowledge of a user being unreachable upfront
> > you can make sure to write a descriptive error, whereas when relying on a
> > server response you are completely dependent on a server giving an error
> > in the first place for a protocol and on the error being unique enough to
> > recognize the situation. Lastly, the parsing would be protocol dependent
> > and thus not benefit from shared code and i18n strings in libkopete.
>
> That's not true...

(...)

You only responded to my last argument, where in fact there are two. The 
former is more important for me, although all the code duplication is a worry 
as well.

Sunday 28 December 2003 14:01
> In that case Kopete could just as well send a dummy message (it wouldn't
> arrive anyway) to find out and report the reason straight away. No need to
> allow a user to type messages that won't arrive for that.

Erg...bad idea.  They might get it, you never know.  Kopete should never send a message that the user did not deliberately type.  That's a good way for a simple bug to make lots of people hate Kopete for spamming them.

> With MSN each chat has its own socket, so just opening a chat window
> already triggers the creation of such a socket and you would find out the
> reason straight away.

Sure.  MSN is weird ;-).

> I don't think either of these belong here though. It makes a lot more sense
> to incorporate this information in the tooltip, e.g. by detecting this
> state if a tooltip is visible for more than a second and updating the tip
> once we know the result, perhaps also caching it.

I don't think we should try to detect it...that just has Bad Idea written all over it.

> IMO this is a typical example of requesting information from Kopete that in
> itself is a very valid wish in the wrong location from a
> usability/architecture POV.

Not according to the design of most other IM clients, but I guess that doesn't matter.

> You only responded to my last argument, where in fact there are two. The
> former is more important for me, although all the code duplication is a
> worry as well.

Your first argument was "We don't know anything descriptive enough".  Well then you make an error message as descriptive as you can based on the information available.

Ah well, this isn't that important and I'm tired of dealing with it.  Closing.

Subject: Re: [Kopete-devel]  Kopete should not preemptively block me from sending messages to offline users, but give me a server error instead

On Sunday 28 December 2003 23:18, Casey Allen Shobe wrote:
> I don't think we should try to detect it...that just has Bad Idea written
> all over it.

Perhaps. I still think the idea is interesting. It's just your proposed 
implementation that I don't like, also because it's rather a power user 
feature to want to know this.

> > You only responded to my last argument, where in fact there are two. The
> > former is more important for me, although all the code duplication is a
> > worry as well.
>
> Your first argument was "We don't know anything descriptive enough".

Eh, no, it was "some protocols might return an error that is LESS accurate 
than our own heuristics. if we know upfront what's wrong it's really useless 
to try anyway.".

> Ah well, this isn't that important and I'm tired of dealing with it. 
> Closing.

Hmm, that wasn't exactly my idea, but it sure helps to get your insane amount 
of usability bugs "fixed" ;-)

Re-report in a year or so when our underlying API and backend is more 
mature :)

Subject: Re: [Kopete-devel]  Kopete should not preemptively block me from sending messages to offline users, but give me a server error instead

Sunday 28 December 2003 18:11
> Perhaps. I still think the idea is interesting. It's just your proposed
> implementation that I don't like, also because it's rather a power user
> feature to want to know this.

Well, it's not applicable to all protocols, and at least with the official AIM 
client, the server error is *NOT* reported (more to follow on the mailing 
list soon about that).  Moreover, I think that the desire for this 
functionality was caused more out of frustration with the AIM problems than 
out of a real need, when I think about it.

> Hmm, that wasn't exactly my idea, but it sure helps to get your insane
> amount of usability bugs "fixed" ;-)

And if you don't think something is a bug that needs fixing (as indicated by 
the quotes), then please change it to a wishlist item.  I try to input bugs 
as accurately as possible, but nobody's perfect :).

Vertu s

*cough*ToldYouSo*cough*

This makes it impossible to message invisible users.  I really like it when they get offended because they think I'm ignoring them, really I do.

I fully agree, this is also applicable with MSN

Yet another agreement.  Many a time my girlfriend goes invisible when she is interested ni chatting with no one but me.  Not being able to chat in cases like that is extremely problematic

>*cough*ToldYouSo*cough*
>
>This makes it impossible to message invisible users.  I really like it when 
>they get offended because they think I'm ignoring them, really I do.

Where do you get this idea? I can message people who are invisible (or offline 
even) just fine on both ICQ and Yahoo. 

This seems like an MSN issue since there are no problems messaging ICQ or Yahoo contacts if they're invisible. However, MSN is a different story because messages sent to offline users aren't saved on the server. Still seems like an invalid or won't fix because (but only because of a limitation in affected protocol)

> Where do you get this idea? I can message people who are invisible (or offline
> even) just fine on both ICQ and Yahoo.

That's because ICQ and Yahoo both allow offline messaging.  AIM and MSN don't.

Kopete preemptively blocks you from messaging contacts it cannot see online for protocols that do not support offline messaging, generating an error for you instead of attempting to send the message, and then returning an error only if the server does.

If you read the original bug report and commentary above, I clearly stated that this was an AIM problem.  Olivier reports that this is also an MSN problem, of which I was not aware.

On MSN, you can't initiate chats is you are offline or appears offline, or if you are blocked.  Anyway, you still can send message if the socket is not closed.

For example, if someone which blocked you sends you a message, you can't reply just because the send button is disabled.

a work around to the problem could be to add KopeteContact::setReachable that msn could call when it detects that the chat socket is still open.

ahh, so you want gaim like behavior for contacts. got it. :)

*sigh*

I'm not asking for gaim-like behavior, I'm asking for behavior consistant with every properly-written AIM client, including the official releases.

The client can not tell if a remote user is offline or invisible (that's the point of being invisible).  However you can message invisible contacts (because otherwise, there's no point to being invisible instead of offline).

> ------- Additional Comments From cshobe osss net  2004-04-16 00:00 -------
> *sigh*
>
> I'm not asking for gaim-like behavior, I'm asking for behavior consistant
> with every properly-written AIM client, including the official releases.
>

Sure you are. I would consider gaim a properly-written AIM client, and it 
(gaim) behaves like the official releases. My saying that you want gaim like 
behavior was my way of characterizing how you wanted it in a way that I could 
understand it and remember (quite easily) how you expect Kopete to behave.

Obviously, you didn't see how gaim did it before responding or you wouldn't 
have responded in the manner that you did, but that's beside the point.

> I would consider gaim a properly-written AIM client

I wouldn't.  I use it often enough to know better.  I don't want "gaim like behavior for contacts", which is rather broad and unclear (and GAIM has plenty of problems with contact handling).  I simply want exactly what the bug summary says, without all the GAIM bugs (which seemed to be what you were suggesting I wanted).

ok, so i played with this a bit, and took out the check in MSNContact::isReachable() that checked to see if the contact was online, but I still get a message box when I open a chat window saying that my messages will not be delivered. 

Is this acceptable? If so, how is it any different than being consistent with the rest of the protocols and displaying the message box before opening the chat window?

Please read the original bug report again.  In no place did I mention MSN, and I don't know/care about it.  I do know that I *CANNOT* respond to AIM users without adding them to my list (I can in any proper client), and I *CANNOT* communicate at all with AIM users who are set to invisible (I can in any proper client).  I explained this in great detail already.

Furthermore, MSN works entirely differently, because it creates a socket between you and the remote party before any messages can be sent.  With AIM, no such socket is created, messages are sent to the server for delivery to the remote party (excepting direct connect, which I'm pretty sure Kopete doesn't support at all).

well, the temporary contact issue should be fixed in CVS, and the not being able to respond to invisible AIM clients (a functionality that was just added for AIM) is a duplicate of 72704, IMNSHO.

*** This bug has been marked as a duplicate of 72704 ***

I am going to re-open this bug... for now I will change it to the MSN plugin since that's the only one I know it affects.

Here's the problem. My fiance uses MSN almost exclusivly in an 'appears offline' mode, so that people don't bother her. *I* know she is online though. But with Kopete I can not message her, since the UI blocks me - it's not even trying to send the request to the server.

If the request to the server was attempted, it would suceed. I know this because I can use other clients to talk to her fine. This is because I am not blocked - she is just 'appearing offline'.

The only way I can talk to her in Kopete, is if she messages me FIRST. The Kopete lets me keep talking in the existing window.

I think the best solution for this, would be to change the current dialog box, from a simple message to one like this:

"This user appears to be offline, and this protocol does not support offline messaging. Messaging this user will likely be unsuccessful. Do you want to try anyway?

<Yes> <No>

Re-assigning this bug as a wish.

Hello,

With the new MSN plugin it should now be possible to send offline messages. And if i understand correctly, this wish is a duplicate of bug #141548. Please reopen if i am mistaken.

Thanks

*** This bug has been marked as a duplicate of bug 141548 ***