[tahoe-dev] uploading unhappiness error messages

Zooko O'Whielacronx zooko at zooko.com
Tue Jan 4 16:30:01 UTC 2011


I've heard from several people that they don't like the complex,
detailed error messages that you get if you try to upload and the
uploader can't achieve happiness.

So these people naturally suggest reducing the amount of information
in the error message to make it nicer to read.

However, please understand that this error message started out being
nice and simple like that, but during the development of #778, I
repeatedly encountered cases where an upload could fail and the error
message could leave the user really mystified as to why it didn't
work. So I repeatedly asked Kevan (the architect of #778) to add more
information into the error message to clarify that case. At the end of
this process, the error message had a fairly complete description of
what went wrong in it -- how many servers failed to accept new shares
and why, what level of happiness was achieved, etc.

Now, it may be possible to make the error message clearer, more nicely
formatted, or even shorter without regressing to the earlier
situation, where a user could be utterly baffled and unable to figure
out why it didn't work. Referring to an explanation outside of the
text of the error message might help.

But if you do so please be careful not to undo the work that Kevan and
I did to avoid cases where the user could be stuck with no way to
understand what happened. You can find almost all of that process
recorded in the giant ticket #778.

I suspect that the problem is inherently complex -- that there isn't a
concise way to completely explain failures of servers-of-happiness.

This would lead us to wonder if the servers-of-happiness design itself
is unnecessarily complex. (Brian has expressed dissatisfaction about
servers-of-happiness a few times.) However, I haven't yet seen a
simpler design with similarly good safety properties, so my current
hypothesis is that erasure-coding your file onto multiple servers just
has inherently complex failure modes, and there is no way to implement
it much simpler than servers-of-happiness, and no way to show error
messages to the user much simpler than the current error messages.

Prove me wrong! :-)

Also, this is further reason, in my mind, to make the default value of
K be 1, simplifying the user experience for first time users in
several different ways.

Regards,

Zooko

http://tahoe-lafs.org/trac/tahoe-lafs/ticket/778# "shares of
happiness" is the wrong measure; "servers of happiness" is better



More information about the tahoe-dev mailing list