Optimization
Implementation.Optimization History
Hide minor edits - Show changes to output
Added line 24:
** 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
Changed lines 3-17 from:
*
*
*
*
*
*
**
**
*** server would have to keep a balance since the last reconciliation
***
to:
!!!! Caching payment paths for reuse
* both used and unused
!!!! 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
* both used and unused
!!!! 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
Changed lines 14-17 from:
*** 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?
to:
*** 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?
** 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
** 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
Changed lines 11-14 from:
** client might specify certain available credit is guaranteed for a certain amount of time on certain accounts
to:
** 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?
** 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?
Changed lines 1-2 from:
!!! Routing Optimization
to:
!!! Transaction Optimization
Changed lines 2-11 from:
* caching payment paths for reuse;
to:
* caching payment paths for reuse, both used and unused
* 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 certain available credit is guaranteed for a certain amount of time on certain accounts
Added lines 1-2:
!!! Routing Optimization
* caching payment paths for reuse;
* caching payment paths for reuse;