Transaction Optimization
Caching payment paths for reuse
Optimizing for cost
- how? doing it explicitly requires knowledge of account units
- might be done implicitly by tracking which payment paths have been chosen in the past and keeping a kind of pagerank for exchanges
- allow client to indicate whether to optimize for speed or for cost
Caching client account data
- client might specify available credit for accounts and exchange rates between accounts
- data could be specified to expire, or could be good indefinitely until next client update
- client could push data, or specify a URL to pull new data when it expires
- either of these models might be simpler to implement for the client than the query/authorize/commit callback model... maybe we should consider starting with these instead?
- client-initiated push-pull only allows client to avoid running an HTTP server
- client may or may not wish to confirm each transaction before it is committed
- server could push account entries back to the client, or client could pull entries from server for reconciliation
- server would have to keep a balance since the last reconciliation
- reconciliation could be "hard", meaning server balance is reset to zero, or "soft", meaning it isn't
- reconciliation + setting new account & exchange data should be an atomic transaction, otherwise transactions that would otherwise affect the client's decision-making might slip in between the two