On Mon, 29 Sep 2014 20:57:51 +0100
Dimitris Papastamos <sin_AT_2f30.org> wrote:
>
Thanks Dimitris for the great introduction!
It goes without saying that the motivation to develop a new client is
also more or less rooted in the quality of existing clients.
While developing ratox in the last two weeks, we had lots of fun
discovering the charming complexity and "stability" of the official
Tox-client uTox (toxic, Venom and others are no exception).
The problem is based on the fact that these programs try to stuff
all solutions into one binary (as it is the norm nowadays).
uTox weighs in at 21k LOC and is thus as complex as the toxcore
itself. This high number is also based on the fact
it has to support Windows as well, but a text-rendering-engine,
ui-toolkit and image-renderer all put together in multithreaded
beauty with an own per-thread-messaging-protocol can be expected
to weigh in a lot.
Respectively, toxic suffers from it's iron will to implement its
TUI in ncurses.
However, both uTox and toxic are not bad clients after all when it
comes to the scope their designers pictured them to work inside.
Nevertheless, considering you should be able to expect a program
to handle arbitrary input and edge-cases without freezing or stalling,
uTox especially fails this test.
TLH and I hit a number of issues in regard to text-rendering and
file-transfers, but just the fact how loosely error-conditions
are checked[0] is close to insanity. Gems like this[1] and double-
renames to force-write a file to disk[2] round it up.
The text-renderer fails the popular UTF8-stress-test[3].
Also, who can remember what msgheight(), messages_updateheight(),
message_setheight() and message_updateheight()[4] do in particular?
Without reading the code, what is the difference between endcall()
and stopcall()?
You get the idea.
As Dimitris already said, the nature of FIFOs allowed us to implement
numerous things without worrying about them too much or even at all.
For instance, offline-text-messages (which as of now are not yet
implemented in uTox) and offline-file-transfers work as expected
(in the latter case the write to the file_in blocks), because most
of the pending-stuff is handled in the Kernel.
It has been a lot of fun to implement it for the sole reason that
once we got the data-structures right, adding functionality was
very trivial in many cases.
Ratox is a prime example where the UNIX-philosophy wins.
Based on ratox, TLH and I will work on a set of scripts/client
rather similar to hysteria[5] with tmux and other tools
(pv, rlwrap, ...), once ratox is more or less feature-complete
in version 0.2.
I hope you have fun trying ratox out and leave us some feedback!
Cheers
FRIGN
[0]:
https://github.com/notsecure/uTox/commit/283fc5dc3266c817cf772e0973cb1cddce5d92c1
[1]:
https://github.com/notsecure/uTox/blob/master/text.c#L210
[2]:
https://github.com/notsecure/uTox/blob/master/tox.c#L620
[3]:
http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt
[3]:
https://github.com/notsecure/uTox/blob/master/messages.c#L754
[4]:
https://github.com/notsecure/uTox/blob/master/tox_av.h#L44
[5]:
http://git.2f30.org/hysteria/
--
FRIGN <dev_AT_frign.de>
Received on Mon Sep 29 2014 - 22:59:17 CEST