We should add methods to allow for removing of orders from the XUD orderbook. This is necessary in the case of a user canceling their order or an order being filled internally. This should have a call through the gRPC layer as well as xucli integration.
It can be implemented on the OrderBook class as removeOwnOrder & removePeerOrder. The later will be invoked when a peer invalidates his order.
The order should be removed both from the priority queue and from the database. We currently maintain them separately, so it's pretty messy.
In addition it also need to trigger invalidation over the P2P network, so a new packet need to be added: ORDER_INVALIDATION.
Does it make sense to add removePeerOrder to the gRPC layer since XChange will never call this ? @moshababo
In addition it also need to trigger invalidation over the P2P network, so a new packet need to be added: ORDER_INVALIDATION.
Yes! Just added this to b) https://github.com/ExchangeUnion/Docs/issues/26
Does it make sense to add removePeerOrder to the gRPC layer since XChange will never call this ? @moshababo
I don't think so. The Own/Peer semantics shouldn't even be used on these calls.
Each xud client can cancel his own orders (by invoking cancelOrder).
As for other peers orders - if he don't want them to enter his node, he can block the peer. But there's no reason to actively remove a peer order - that's something that only the P2P layer should do, when cancelOrder was invoked by a remote node.
From an API perspective, I prefer the removeOrder naming because it is generic. The exchange should call it both when an order is cancelled and when an order is filled internally. Correct me if I'm wrong but from xud's perspective I believe the two are equivalent.
agree with Daniel's removeOrder naming, because more generic @itsbalamurali @moshababo
I discussed this with @sangaman, and we agreed that cancelOrder is more appropriate.
The reason: removeOrder makes sense only in the context of a local order book API (and that's how it should be implemented there), but not for the high-level API, which also need to trigger invoices cancellation, and invalidation over the P2P network.
In regards to what @sangaman wrote above - it doesn't really matter if the exchange is cancelling it
due to internal cancellation or filling. From xud perspective, it's all the same.
kk, let's keep it final from now on: cancelOrder
Fixed in #206