Complexity of mutability

[Adam Hunt]

I'd like to thank both Brian Warner and David Stainton for their replies to
my previous message regarding the implementation details of Tahoe-LAFS.
After digging into the information I was given I feel that I have a better
handle on the details of Tahoe. Reading up on Merkle Trees was especially
enlightening.

Something that I've been wondering since then is the complexity introduced
by mutable files. In a few use cases that I've been thinking about
mutability is unnecessary and potentially even a liability. How much
complexity is introduced into Tahoe's design to allow for mutabile files?
If mutability was eliminated from an implementation of a system based on
Tahoe's design would the system become appreciably less complex?

In a particular use case that I'm toying with there is no valid reason for
data to be modified once it has been stored. Deletion of old data is the
only case where a file/dataset would be useful. Essentially, I'm interested
in using a Tahoe based system as a temporary store until the data in
question can be moved to a more permanent store.

The reason that I ask about the complexity of the implementation is that I
would likely need to port Tahoe's code to a language other than Python. I'm
interested in using Tahoe or a Tahoe derived system on a system of
distributed microcontroller based devices where running a Python
interpreter would be difficult if not impossible.

Has anyone attempted an implementation of Tahoe's userspace components in a
compiled language? C/C++, Go, Rust, etcetera?

Thank you for your time,

Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tahoe-lafs.org/pipermail/tahoe-dev/attachments/20150806/da1d9981/attachment.html>