Re: Summary of the situation with the composition process — thoughts wanted
mnyromyr at tprac.de
Tue Jun 28 22:31:14 UTC 2011
Jonathan Protzenko aber hob zu reden an und schrieb:
> * Make the composition code more accessible to developers. Hacking
> into that C++ code is insanely hard, the entry cost is high, and
> it's scary. Writing it in JS would make it more concise, lighter,
> and more hackable.
I beg to differ.
C++ (or rather: C, when talking about libmime's core) and JS are just
different languages for different purposes. Every language is "scary" to
those who are not proficient with it. (Including me, of course!)
We have structural problems caused by negligence,
we don't have a language problem.
The biggest disadvantage of JS is still speed (due to being a
interpreter language), but this, too, is a not an issue with today's
hardware anymore, even without JIT.
> We could also drop large chunks of code that make no sense today :
> the C++ code goes great lengths to figure out the best encoding to
> sent the outgoing message with. In compose in a tab, I settled for
> UTF8 always, and saved myself a lot of trouble.
Yes, that may be non-issue today when composing, but wrt Germany, many
mails are still written in iso-8859-15 or even windows-1252.
> Allow experimenting with new designs, such as compose in a tab.
The latter is not bound to a specific language. ;-)
More information about the tb-planning