Version: (using KDE Devel) Installed from: Compiled sources If I paste a whole arseload of text into a chat window and try to send it, it does not tell me that the text was too long, only that the other user has closed the socket and that my message did not get sent correctly. I've also had problems with long messages on Gadu-Gadu and other protocols. IMHO, the choice from the SMS plugin (regarding what to do when message length is exceeded) should become a global choice in Kopete configuration, and each plugin should just be able to tell libkopete what the maximum message length for that protocol is.
Yes i know, the size of a message is limited to 1664 char (header included) (and that's because the header is included that it's hard to calcul the max size since i don't know the header's siez in advance)
Couldn't you just create the whole message you were going to send (header included) and then make sure it's length is less than 1664 characters? I don't know how you'd notify the user that the message didn't get sent, but you might be able to use an existing string for that.
Subject: Re: [Kopete-devel] Large messages close socket on MSN (and other problems) Isn't it even simpler to just limit messages to, say, 1600 characters even if they could be a bit larger. It's like a user is going to care if a message is 20 characters too small on a total of 1600+ :) (Unlike e.g. SMS, which is limited to 160, where every char counts.)
Subject: Re: Large messages close socket on MSN (and other problems) Martijn Klingens (Friday 19 December 2003 03:22) > Isn't it even simpler to just limit messages to, say, 1600 characters even > if they could be a bit larger. It's like a user is going to care if a > message is 20 characters too small on a total of 1600+ :) Yes, they are. This is why the choice in SMS between cutting of a message, breaking it into multiple, or cancelling the message, should apply to all protocols. If the user wants to send large messages, they should be able to without problem in whatever manner they see fit. Furthermore this makes more sense as a single global option than a protocol option. On a related note, split messages should be each shown as a separate message (this is not currently the case on IRC, where a message is split at every linebreak - Kopete just shows one message to you even when you send 20).
Subject: Re: [Kopete-devel] Large messages close socket on MSN (and other problems) On Saturday 20 December 2003 12:07, Casey Allen Shobe wrote: > > Isn't it even simpler to just limit messages to, say, 1600 characters > > even if they could be a bit larger. It's like a user is going to care if > > a message is 20 characters too small on a total of 1600+ :) > > Yes, they are. Are they? Do you really want to send 1621 characters per messages instead of 1600? Come on, with those figures it's really not an issue anymore, I'm not talking about the 160-char limit of SMS here. > This is why the choice in SMS between cutting of a message, > breaking it into multiple, or cancelling the message, should apply to all > protocols. Agreed. > If the user wants to send large messages, they should be able > to without problem in whatever manner they see fit. Furthermore this makes > more sense as a single global option than a protocol option. I think it should be an account option. I'm still considering to make the SMS plugin capable of sending messages through my phone's data cable, so the receiver sees my phone number in the message. But in that case I'm actually charged for each message, so I'd want a different setting for SMS. > On a related note, split messages should be each shown as a separate > message (this is not currently the case on IRC, where a message is split at > every linebreak - Kopete just shows one message to you even when you send > 20). You mean at the sending end? Otherwise please explain how the receiver can detect the difference between split messages and multiple independent messages. If at the sending end, yes, I agree.
Subject: Re: Large messages close socket on MSN (and other problems) Martijn Klingens (Saturday 20 December 2003 06:48) > > Yes, they are. > > Are they? Do you really want to send 1621 characters per messages instead > of 1600? Come on, with those figures it's really not an issue anymore, I'm > not talking about the 160-char limit of SMS here. I think you're talking about something else. I am saying that a user is going to care if they send a 3000-character message and only 1600 characters get through and they have no way to change that behavior to split across multiple messages. > I think it should be an account option. I don't think account-level configureability for this that necessary, but okay. > You mean at the sending end? Of course.
Subject: Re: [Kopete-devel] Large messages close socket on MSN (and other problems) On Saturday 20 December 2003 14:10, Casey Allen Shobe wrote: > I think you're talking about something else. I am saying that a user is > going to care if they send a 3000-character message and only 1600 > characters get through and they have no way to change that behavior to > split across multiple messages. Oh, ok, I agree there. I was talking about the per-message limit. Actually, I wouldn't object to simply limiting the amount of characters that a user can type in the edit box instead of splitting messages (at least for KDE 3.2). > > I think it should be an account option. > > I don't think account-level configureability for this that necessary, but > okay. Well, generally I agree, but in the case where you pay per message (SMS through phone) it makes sense to have a separate option. Perhaps add the ability in the API to have per-account options, but have the GUI only there where it matters?
*** Bug 71195 has been marked as a duplicate of this bug. ***
Some of the info garnered from 71195: When I was reproducing this, the error code returned was EAGAIN so the socket would block if we were actually to do a write that large. I remember Thiago saying that the kernel buffers for sockets are pretty large, so i don't think that would be the problem. Thiago (hi! :) : do you have any other suggestions or possibilities?
You marked this as duplicate, but I don't think it is the same bug. This bug: don't use a buffered KExtendedSocket and, instead, buffer the queued up messages using a QValueList and send them on a timer or something. Make sure the socket is non-blocking and the EWOULDBLOCK errno not being an error. Even better would be to use a QSocketNotifier when the first EWOULDBLOCK error occurs -- so that you don't poll through write(2) unnecessarily. That bug: it was a KExtendedSocket misfeature: a buffered socket can block. Easily solved with setBlockingMode(false).
Something needs to be per-account (or at the very least, per-protocol) about this. Since for SMS I want to send messages with the "Linked: n/m" headers that most modern phones support, I want to be able to say whether or not to do that. Also, how do people feel about splitting in the middle of / between words?
A method in libkopete should be added to count the number of char in a message. *** This bug has been marked as a duplicate of 66202 ***