search

FellowTraveler / Open-Transactions-old

Open-Transactions democratizes financial and monetary actions. You can use it for issuing currencies/stock, paying dividends, creating asset accounts, sending/receiving digital cash, writing/depositing cheques, cashier's cheques, creating basket currencies, trading on markets, scripting custom agreements, recurring payments, escrow, etc. Open-Transactions uses strong crypto. The balances are unchangeable (even by a malicious server.) The receipt history is destructible. The transactions are unforgeable. The cash is unlinkable. The cheques are non-repudiable. Etc.
http://opentransactions.org
407 stars 84 forks source link

modularity / bloat #63

Open FellowTraveler opened 12 years ago

FellowTraveler commented 12 years ago

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.)

FellowTraveler commented 12 years ago

Another thing: Now that the client-side scripting is solid, and scripts are starting to pop-up which automate the command-line functions, then it's time to start removing many of those same functions from the ot command-line itself. The reason is because it simply duplicates what is already done in the API at a low level, and in the scripts at a high-level. Why have the OT CLI commands at all then, when its command-line functions should be oriented exclusively towards options for executing OTScript? It's just extra code that's not needed anymore. The script versions are better anyway, since they automate the details of syncing request numbers, syncing transaction numbers downloading box receipts, yadda yadda yadda. (And all the low-level calls are still possible as well in the scripts.)

Furthermore, the OT prompt duplicates all of those commands again, and could be entirely removed now, and replaced with a ChaiScript prompt (which is similar to python prompt, with full access to the OT API.) This should make it possible to strip a lot of code out of xmlrpcxx.cpp, OTClient.cpp, and OTServerConnection.cpp.