PluginVirtual basically has two functions: the ledger and the codec.
While working on https://github.com/interledgerjs/amundsen/pull/2/files#diff-034b86edf6fcd40d95d1588b485d6d9e it occurred to me that it would probably make sense to make the virtual ledger inside src/lib/plugin.js more explicit.
If we define an in-memory ledger, whose interface is the LPI, it can:
- expose the LPI interface of the plugin (e.g. to the connector when this plugin is used in ilp-connector)
- keep track of the balance
- expose an LPI interface to the outside (e.g. to the peer when used to connect to a peer).
ledger.myPlugin.getBalance() === -ledger.peerPlugin.getBalance()ledger.peerPlugin.sendTransfer() triggers ledger.myPlugin.on('incoming-prepare')- etc.
A separate part of the code can then act as a codec, deal with translating between LPI and BTP and back (see interledger-deprecated/btp-toolbox#2 for an example).
Separating the peer-ledger, which exposes two LPI interfaces (ledger.myPlugin and ledger.peerPlugin) makes LPI more important and confines the impact of BTP to inside the codec. A nice separation of concerns, maybe?
PluginVirtual basically has two functions: the ledger and the codec.
While working on https://github.com/interledgerjs/amundsen/pull/2/files#diff-034b86edf6fcd40d95d1588b485d6d9e it occurred to me that it would probably make sense to make the virtual ledger inside
src/lib/plugin.jsmore explicit.If we define an in-memory ledger, whose interface is the LPI, it can:
ledger.myPlugin.getBalance() === -ledger.peerPlugin.getBalance()ledger.peerPlugin.sendTransfer()triggersledger.myPlugin.on('incoming-prepare')A separate part of the code can then act as a codec, deal with translating between LPI and BTP and back (see interledger-deprecated/btp-toolbox#2 for an example).
Separating the peer-ledger, which exposes two LPI interfaces (
ledger.myPluginandledger.peerPlugin) makes LPI more important and confines the impact of BTP to inside the codec. A nice separation of concerns, maybe?