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 _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
