Architecture NBT data for add-ons is needlessly sent over the network

[SolraBizna]

Currently, when an Architecture has a non-trivial save method, the data thus saved ends up in the NBT of the case/server/whatever is running that Architecture. This is then sent over the network to all clients, just like any other piece of first-class world data. Leaving aside issues of privacy and wasted bandwidth, I'm told this can lead to connection termination if a large amount of data is saved and subsequently sent. (I haven't run into this issue with my own Architecture yet, but it also has tiny memory modules.)

OpenComputers internally has SaveHandler, which NativeLuaArchitecture uses to store its data in a safe way, out-of-band from the chunk NBT. If SaveHandler were part of the API*, Architecture authors could use that to store all their data safely. But then the load/save methods have very little point, and the burden is on each Architecture author to 1. realize that SaveHandler exists and is important, and 2. use it correctly. (Arguably better than the current situation, which either requires calling directly into OC internals or—much worse—implementing your own SaveHandler-type logic, which will almost certainly have subtle bugs.)

I have been unable to come up with a non-contrived scenario where an Architecture actually wants its data to be sent over the network, or stored specifically in the chunk's NBT. Therefore, I suggest a simple wrapper around the calls to the Architecture's save/load methods, which transparently uses SaveHandler to save the data if there is any data to save. If this is done universally, all existing Architectures that assumed save/load were the right place to save/load their data (for some reason) will work. Alternatively, it could be done with an abstract class in the API, which Architectures that have no data to save "unsafely" could specifically subclass.

*If I had a nickel for every time something important only to Architecture authors turned out to be missing from the API...