FellowTraveler/Open-Transactions — Issue #63: modularity / bloat
Author: FellowTraveler
Created: 2012-02-06 19:56:10+00:00
State: open

There is lots of bloat that can be targeted...

SFSocket class can probably be removed without too much effort. It would require removing the TCP transport (we use ZMQ now anyways.) Probably could remove a good chunk of code by doing this.

I believe that MsgPack and Protobuf are both separated out via compiler option. Therefore it shouldn't be too hard to pick one, and not have to build / link to the other. Both might appear in the source but only one should appear in the linked binary (need to make sure.) ALSO: the current working version, protobuf, was due to the fact that we couldn't get msgpack working on other platforms IN A DLL. But would be nice to fix this, since I bet MsgPack is SMALLER and FASTER. (Protobuf might be safer.)

Probably can remove STLplus, and go around the code adding various C++11 smart pointers instead (some of those are used already from tr1.) Could probably go around the code and remove all the deletes (replace with smart pointers.)

Should make sure there's a compiler option for removing the scripting. Although scripting may be desirable on the desktop and on a server, it's probably entirely superfluous on an Android phone -- and having a clean preprocessor directive for this would slice out chaiscript as well as boost (I otherwise do not use boost at all.)

Probably could remove OTAPI.cpp by merging all of its functionality into OTAPI_Wrapper.cpp instead. It's definitely better to use std::string instead of char * (buffer overflows, for example) but just need to make sure that SWIG can handle it that way.

Soon Moneychanger will run as a systray icon and all the plugins from other apps will just talk to that systray plugin. If there were a version of the systray plugin that used OT directly, instead of going through SWIG (for example, in a QT app) then the SWIG and API layer could be removed, and the new high-level interfaces would be built around whatever IPC is used for talking to the systray icon (possibly ZMQ again, or possibly a web API.)

The storage code is good, but possibly the XML serialization in OTContract-derived classes could be reduced.

This is all low-hanging fruit and I'm sure there's much more that could be done, including a fresh Valgrind scan, a security audit, and other goodies. (But I just wanted to make myself a list.)