Tue, 19 Nov 2013 16:48:33 GMT
External Content not shown. Further Information. I use instant messaging a lot, since many years, and had a lot of different software running, with its own genuine problems and advantages.
In the beginning, it was the time when ICQ became popular, and I used the official ICQ client under Windows 98. It made typewriter sounds on every character that one typed. It was the first software I can remember that did not exit on close, but minimized to tray by default.
However, it had a lot of eyecandy, and needed a lot of my 64 MB RAM, and crashed often. So, at some point, I switched to Miranda IM, which was much better. At that time I got to know IRC, and joined a few IRC channels through Miranda IM. I only had a dial-up connection, which probably had some package loss and a high latency, so it was often the case that Miranda IM warned me that some message could not be sent. When "retrying" to send the message, it sometimes arrived multiple times.
At some point I switched to Linux. At that time, it was not as easy as today to get a working ICQ Client under Linux. So in the beginning, I used ICQ2GO which is now called Web-ICQ. Nowadays, it uses JavaScript. But at that time, it used a Java Applet - which also swallowed a lot of RAM and did not have the Quality under Linux that it has today, and also crashed often. This became even worse when they ported it to Macromedia Flash, which really was a pain at that time (it still is a pain sometimes).
I do not know exactly in what order I used which clients after that. For a long time, I used SIM, but for some reason I did not keep using it, not sure why, probably there was a lack of compatibility with a linux distro I wanted to use (since other software sucks too).
Kopete used to be the standard messenger under KDE, and I liked it, but at that time, it had one problem: Others received my messages, but sometimes, their messages did not arrive. I still have no idea why, and I am not really interested, but they apparently fixed it. Then there was GAIM, which was later renamed into Pidgin. It has a lot of flaws, but sort of works. Furthermore, at that time I started using Jabber, and sooner or later arrived at Psi, which is a pure XMPP client, but supports transports. But the transports … sucked.
At some point, I discovered BitlBee. And used it with Irssi. From that point, I mostly used either Pidgin or BitlBee. When I started studying, it was the first time when I really had the problem of syncing many computers. Mostly I used Pidgin on every computer, and synced the directories - this was not perfect, but sufficient.
And there we almost come to the current setup: A central server with a tmux session. I tried Centericq and Finch, but they did not convince me, so I preferred BitlBee and Irssi. Though, I missed notifications via libnotify, which are sent by some other clients.
We are now approaching the part where I try to "fix" software problems
myself. Of course, Irssi is scriptable, and there is a setting to let
it execute a command when receiving messages. But instead, I wanted a
more general solution for other purposes. So I thought it might be
possible to tell some terminal emulator to execute a command, when a
BEL character arrives. Apparently, such a terminal emulator does not
exist, so I experimented with terminal stuff myself. I found the
forkpty(3) function, and I am able to write such a piece of software
now, but I lost interest.
In the meantime, I began using mobile internet, which … sucks in some
places, so it happens that connections get lost. Directly using Pidgin
and other clients, message loss occurs, but running BitlBee on a
server with a good connection works well, and thanks to the tmux
session, I can always reconnect a broken ssh connection. But as
reconnecting gets on my nerves, I switched to
mosh. So until I got a smartphone, my instant
messenger software stack consisted of bitlbee behind irssi behind tmux
behind mosh. Yes, that sounds complicated, but one fundamental
principle of Unix is todo one thing and do it right, and every part of
this software stack does its job pretty well - at least on personal
computers.
On my small smartphone, it is a pain to use terminal applications. There is the Hacker's Keyboard, which I use, but which does not show the relevant keys in portrait mode, and makes the terminal half as big while typing, even in its experimental transparent mode. There is an app called Transparent Keyboard, which really is a transparent overlay keyboard, but the keys are too small on my screen, so this is not an option for me. Both keyboards are probably very useful on large displays, but on my display, this is unusable.
In my opinion, terminal applications have a completely different UI model than most other apps on Android. They usually focus on the keyboard, while smartphone UIs focus on the touchpad. So it is legit not to use the system's input method, but having an own one. I would suggest a semi-transparent overlay keyboard over the whole terminal: Most terminal applications do not support mouse input, so there is never a reason to actually touch the terminal window itself. On the other hand, relevant information is shown in most of the text window, so it is desirable that this text window uses most of the screen. So I guess this is reasonable.
So recently, I am using Quassel. It has
several advantages over IRC bouncers like
bip, and fits my needs comparably
good. But it also has some problems. One thing is that currently, the
Android client does not do compression. A workaround that works fine
for me so far is to turn off SSL encryption in Quassel, and tunnel the
traffic through a compressing ssh connection, which I generate with
ConnectBot. ConnectBot is also
not completely flawless: In some configuration it always needed huge
amounts of processing power, thus lowering my battery, which is why I
do not touch the current settings at all. And well, it hangs up
occasionally, and sometimes Quassel refuses to connect to the
forwarded port for no apparent reason. And it still takes ages to
connect, even though I set the backlog length to 1 already. Quassel
seems to always send, besides its whole core configuration, all
messages that arrive in all channels you joined. However, on a mobile
internet connection, I want traffic to be reduced as much as
possible. It would be nice if only state changes ("highlighted",
"unread messages", etc.) of channels in which I only idle around were
sent, and the messages are only loaded on demand. The usual behaviour
of IRC chatters is to idle in a lot of channels and only occasionally
look into them.
Besides that, I recently began to join some XMPP Groupchats, which
does not really work properly in BitlBee, at least in my version. It
has problems with unicode nicknames, and does not restore these chats
after I log out of a session. However, I have workarounds for this,
and on the whole, BitlBee works well for me. But it is still an IRC
gateway to different chat systems, which inherently comes with some
compatibility problems, one of them being the fact that IRC messages
cannot contain line breaks, while most IM protocols allow
this. Especially when pasting text, the other side gets the text
chunked into its lines, and this is really annoying. The solution it
provides is the paste_buffer and paste_buffer_delay setting, in
which you can set a time in Milliseconds that indicates when two
consecutive IRC messages are packed into one single IM message. So
when you paste a long text into your IRC client, and it sends them
sufficiently fast, this is a good approximation … except that Quassel
will not let you send pasted text reasonably fast, due to a "feature"
called "flood control", which apparently
cannot be turned off. This
is a desirable feature on public networks and channels, in the sense
that it protects you from accidentally flooding. Well, it does not
really protect you, it apparently just delays the messages a bit,
which is - in my opinion - even worse than just sending them
directly. It forces without warning. Irssi asks you for an
affirmation when it notices that a lot of messages are typed in at
once, if I remember correctly, one has to confirm with Ctrl-D. It
warns without forcing. That is an important rule, I shall call it
Uxul's 5th rule:
Good software warns without forcing. Bad software forces without warning.
However, both pieces of software have their unique advantages and disadvantages.
In the end, one question remains: What to do about it? While my current setup works fine for the moment, it is not satisfactory on the long term. So let me discuss a few alternatives I or other people came up with:
Buy a new phone
I will probably buy a new phone with a larger display sooner or later, and thus solve some of the problems. But I do not consider solutions of the form "throw hardware on your problems" as good. I am pretty sure that I will run into other software problems with a new phone.
Irssi ConnectBot
There is a fork of ConnectBot, called Irssi ConnectBot, which I would probably use on the aforementioned hypothetical new phone. However, it makes use of input buttons my phone does not have, and it uses swiping, and I hate swiping and gestures in general, because they often fail when you have stubby fingers. Furthermore, it confuses my configuration of ConnectBot, when installed parallely.
Writing or patching an existing terminal emulator…
…in the way I described above might be worthwile even for other applications, but both getting an own implementation stable and understanding another implementation are a pain and take long. This is probably a nice project for it own sake, but not for this specific problem.
Irssi-Proxy with bouncer
There is an Irssi extension called irssi-proxy, where Irssi exposes its connections, so a second client can access them. Then I could just run a bouncer on these exposed connections so I get the backlog. However,
Writing an own new IRC Client
Years ago I programmed an IRC Bot with Java, using TCP sockets, but implementing the IRC protocol myself. It is a comparably simple protocol. A suspendable web-based client would be perfect, as it could be made accessible on both PCs and phones with little effort. I considered using Common Lisp, Hunchentoot and cl-irc, and producing a simple web-based client should be very easy. On the other hand, it would produce one more piece of software that is poorly maintained and has its own unique flaws, without really adding any value. The better alternative would be …
Writing a Web-Frontend for Quassel
The advantage of Quassel is that it already has a lot of infrastructure for distribution of configuration settings and their meanings. And once running, there might be enough interest to keep such a project alive, even in times when I can not actively do so.
Writing a Web-Frontend for Irssi
Irssi is scriptable. There already exists a frontend for it, but it looks anachronitic (the link for the current development seems to be dead). However, the Irssi-API looks nice, signal-based, sufficiently nice to make such a project possible.
Writing a purple-based Web-Client
…and probably failing like the many people before. But it might be worthwile for its own sake, as an exercise to learn libpurple, and knowing an advanced multi-protocol chat library might be an advantage in many ways. There is this nice introduction to libpurple. Of course, I am not the first one with that idea, there is at least WebPidginZ which I did not try yet due to the lack of time. Furthermore, there is the Broadway Backend for GTK, so maybe Pidgin will run on it.
Just wait and use workarounds until somebody else does the work
This is the most probable thing I will do. And probably also the most probable thing most other people do. And therefore, probably the reason for all of that mess.