Hacker News new | ask | show | jobs
by mmooss 235 days ago
> What is profit to have good server with new good (assume it is good, I'm not sure, but lets assume) protocols without good client?

You need both. You could say, what profit is a good client without a server? By that reasoning, we never stake a step forward without a complete solution.

Now a better mail implementation is just a client away.

1 comments

Problem with clients not protocols but UI&UX. New protocols can change nothing in this area.

Maybe, Apple Mail is good, again, I don't know as I'm not using Apple, but I don't know any client for Windows and/or OSS with Windows support which has as basic features as support of per-folder settings (identity, sorting mode, etc.) stored on server or proper support for Sieve. In my eyes it is basic features.

And don't let me start to rant about message editor itself, especially in text-only (as opposite to HTML) mode with proper quoting & such.

On a tangent: For do you use format-flowed in text-only that you send? I'm never quite sure if it's universally and effectively supported enough to implement for less-technical users, or better to just define the EOL (and lose dynamic adjustment to viewer width).
I had complains about "too long lines" in my e-mails many times and now try to use EOLs, unfortunately.

It is exactly what I said: all modern, GUI e-mail clients suck at basic functions, like displaying simple message with several layers of quotations and long lines, they cannot wrap lines with visually duplicating quotations properly, often they could not wrap even "new" (unquoted) lines at all and show horizontal scrollers. JMAP is no help here.

It was solved problem in age of terminal clients, heck, GoldEd for FIDOnet was able to do this in 1990s.

Instead of new protocols it was better to standardize MarkDown (+extension for nested quoting) in e-mails, but this train is long gone, I'm afraid.