discussion: client order archiving
In working through #2975, it became clear that we needed solutions with more nuance. We'll use this issue to discuss a proper solution for order archiving.
- We'll want to give users some control over how orders are archived. These controls will need to be available through the UI.
- We should keep in mind that future functionality might benefit from having a full order history. An example might be a chart that graphs trade history. In this case, we won't want to delete archived orders outright, but we can almost certainly reduce their footprint by e.g. deleting signature data from proofs, or creating a parallel archive that encodes only the minimum pieces of relevant information.
- Users may want to limit archived orders to a certain number of orders, or only until a certain age, or even limit the amount of disk space allocated to the archive
- Users may want to archive orders only in combination with a backup process where they can move the records to a separate file.
Users may want to limit archived orders to a certain number of orders, or only until a certain age, or even limit the amount of disk space allocated to the archive.
I think the first update should be to implement this, but only for unfilled orders. This will fix the issues people are currently having. Reducing the footprint of filled orders and providing a way to backup records are also good ideas, but less urgent IMO.
I agree with what @martonp said on the pr, just delete any orders that did not match. Delete all canceled orders and cancel orders. Anything that did not move funds is useless for record keeping right? If we just did that I assume there would not be a problem?
related to #2945
When I implemented test code to experiment with issue #3054 I was acutely aware that the current web-socket would have a big increase in traffic. I implemented a ring buffer in the ui to just stash the last N loglines from bisonw and also thought of adding a websocket just for loglines. A year ago with a couple of markets none of these kinds of issues showed up. But now there is a need for a more holistic approach that satisfies both the ui and the need for data.