Quote from: etotheipi on March 09, 2013, 03:25:25 AM

Honestly, it's not hard at all -- but there is tremendous value in the simplicity of the current design. Armory is a very large, complicated beast. Any time I can come up with a solid solution that doesn't requiring maintaining/synchronizing new files to disk, and doesn't require any new interfaces, data entry, error checking, etc -- is better for me and less bugs for users. Pulling all the data from the blockchain scan and organizing it into a table is pretty darned easy.

Most importantly, is that I get to avoid all issues with serialization/deserialization, and partially-written/corrupted files that crash Armory. It works 99.99% of the time, but then I spend many hours chasing down bugs for users that ends up being a corrupted address book file, or a bug in the code that reads/writes the data incorrectly and corrupts other things, causes crashing, or just a cascade of buggy behavior. In fact, I have had this happen with mempool.bin, and is actually why I added the "Revert All Settings" tab.

On second thought, this could piggyback on the Armory wallet file itself. Create a new entry type and create an interface for converting user data into the new entry type. This is favorable, because the wallet files have some corruption resistence to them, and it makes sense to put address-book data in there anyway.

I understand what you're saying. More features = more problems.
But there are plenty of lists being populated already. Is populating a list of something like addresses/comments different than the others?
Eh, i'm sure I can test it out myself.