Hey,
Good job guys. I just read the site and both your write-ups and I've
got to say this seems very appealing to me. I love how the software is
not reliant on vt100 terminal emulation or huge libraries. Your FIFO
approach seems great as well.
Keep up the good work. Looking forward to release 0.02!
Regards
Lee
On Mon, Sep 29, 2014 at 4:59 PM, FRIGN <dev_AT_frign.de> wrote:
> 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 - 23:28:15 CEST