You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
How about a new API that returns an order book that orders are grouped already? I think we can group the orders by percentage increase on price, we can say that a group of orders is a bucket, say 0.01% buckets, 0.1% buckets, 1% buckets and etc.
An order group (e.g. an ask order group) would have there attributes :
max_price: the greatest asking price in the group
min_price: the least asking price in the group
total_for_sale: the total amount of asset that is being sold
And perhaps one or more of these attributes are useful (to determine when to execute a new query, to subscribe to market order objects, to update user balance info and history, etc, although personally I think it's inefficient for UI to subscribe to order objects in busy markets in comparison to polling):
min_expiration: the earliest time that an order in the group may expire
id_array: a list of order object ID's
seller_array: a list of sellers, maybe sorted by whatever attribute and/or have duplicates removed
In order to implement this, the simplest way for the backend would be calculating on the fly which will use no extra RAM but every query uses CPU, the way with highest query performance is an plugin that has data pre-calculated with pre-defines buckets. Personally I prefer the latter, in this case we should define a default bucket list for both the UI and the backend, and more to discuss if we go in this direction.
We can add similar API's for force settlements and call orders later.
How about a new API that returns an order book that orders are grouped already? I think we can group the orders by percentage increase on price, we can say that a group of orders is a bucket, say 0.01% buckets, 0.1% buckets, 1% buckets and etc.
An order group (e.g. an ask order group) would have there attributes :
max_price
: the greatest asking price in the groupmin_price
: the least asking price in the grouptotal_for_sale
: the total amount of asset that is being soldAnd perhaps one or more of these attributes are useful (to determine when to execute a new query, to subscribe to market order objects, to update user balance info and history, etc, although personally I think it's inefficient for UI to subscribe to order objects in busy markets in comparison to polling):
min_expiration
: the earliest time that an order in the group may expireid_array
: a list of order object ID'sseller_array
: a list of sellers, maybe sorted by whatever attribute and/or have duplicates removedIn order to implement this, the simplest way for the backend would be calculating on the fly which will use no extra RAM but every query uses CPU, the way with highest query performance is an plugin that has data pre-calculated with pre-defines buckets. Personally I prefer the latter, in this case we should define a default bucket list for both the UI and the backend, and more to discuss if we go in this direction.
We can add similar API's for force settlements and call orders later.
More info in bitshares/bitshares-ui#1106.
The text was updated successfully, but these errors were encountered: