Xud: placeOrder / placeOrderSync

[offerm]

It would be nice to have a wait option of buy/sell market order.
These can block until the trade is done and the result is available.
The result is not just the match(s) but also the outcome of the execution (swap for example).
If can also show the impact on balance once we have it.

[michael1011]

123 is doing that.

[offerm]

Thanks. Noticed.
Not sure why we mix the discussion of Subscribe calls with placeOrder call.
I envisioned something simple. clearly not complicated as the discussion in #123.
Will take some time to go over #123 and digest it.

[sangaman]

We can maybe use this issue to track the synchronous placeOrder mode which waits for all swaps to complete (or fail), as an offshoot of #123. @moshababo have you worked on this any more or thought more about how that would look like? I know you'd discussed using an approach similar to the peer ResponseEntry model.

Edit: Sorry, hadn't seen your most recent post in #123.

[sangaman]

@moshababo's most recent post:

Designing the new API should take #145 into consideration. I'd suggest to discuss it first before implementing.

In regards to having a synchronous version for placeOrder, i'd suggest to utilize Peer.wait in order to create a synchronous code flow in Swap.beginSwap (which could be awaited from OrderBook.handleMatch, and so to affect MatchingResults). I think this change would be good for our code base, regardless of placeOrderSync.
The actual LND call is synchronous, so we don't need extra work there.

The other option is to manage a global state for the swap procedures, which I think would be a far worse solution.

I think this should be implemented separately from the high-level API changes. Let me know if you want me to work on it.

If we go forward with placeOrder and pIaceOrderSync calls, which I still think is best, we can have only placeOrder active for non-matching mode. It will behave the same, returning an empty response immediately as long as the order is valid, the only difference is there won't be any streaming events following it.

You should take a look at #468 if you get a chance, it has a new swap flow and it does use a swap status to track which point of the swap process it's at currently. It has fewer steps and is less reliant on peer packets to advance each step of the flow, so I'm not sure if we can use peer.wait all that much, but it does fire events Basically what I'm thinking is:

• on swap.rejected or swap.failed abandon the match, remove the limit order from the order book, and try to match with a new order.
• on swap.paid consider the match final and add it to our list of matches for sendPaymentSync - or publish an update to the grpc order subscription for sendPayment.

[moshababo]

@sangaman tracking the swap status is fine if it's not done merely to support placeOrderSync. If that's already done, then we can simply listen on the swap events instead, while hanging OrderBook.addOwnOrder until we get the results. It might require refactoring to Swaps class - making deal a class by its own, enabling direct event listening, and not only global listening (which is more suitable for maker swaps, that were not triggered by the API).

I can work on it if you think the new swap protocol is stable.

[kilrau]

I think all covered by #123 now, updated some things in there. Please check @offerm @sangaman @moshababo If you believe we still need this please reopen and describe clearly.

[moshababo]

I think we should keep this one open. It's a subset of #123 that should be done separately. placeOrder / placeOrderSync isn't about order book state events, but about matches/swaps results.

[kilrau]

ok, just referenced it in #123

[moshababo]

@offerm @sangaman let me know if I should already start working on this.

[kilrau]

What's the status on this one? @moshababo @sangaman

[kilrau]

Let us know if there are any issue scoming up during implementation @moshababo