getorderbook_MP: lookup of one property

[dexX7]

It certainly is a difference, if one would call cancel-pair MSC MIndiv or cancel-pair MIndiv MSC, but I'm wondering how to deal with this in the context of getorderbook_MP. Let's say:

A1 offers 10.0 MSC for 10 MIndiv

getorderbook_MP(MSC, MIndiv)   ->   1 result
getorderbook_MP(MIndiv, MSC)   ->   0 results  <<
getorderbook_MP(MSC)           ->   1 result
getorderbook_MP(MIndiv)        ->   0 results  <<

Because it's basically a one-sided orderbook anyway, I don't see much difference in a different order of the properties. I have a difficult time to get my head around the concept, because I try to think in terms of "buy" and "sell", but it doesn't really seem to work.

So let me ask:

1. Any objections to provide the offers, if one property is provided and either one of an offer's properties is a match?
2. What's your opinion on the order of properties, if getorderbook_MP is called with two properties? Is there a real world use case that justifies a strict order or one that speaks against it?

[zathras-crypto]

I tend to view each 'pair' as a 'market' and try present both 'sides to that pair (MSC/PROP & PROP/MSC) from the same view providing that 'buy/sell' feel (though it's not intuitive with our DEx, hence the attempt to make it intuitive at the UI layer).

I haven't spent much time on the orderbook RPCs (Faiz did those) but I'd be inclined to think we need to stick with the order book for the pair supplied. In the example above I do this by providing two order books (a buy and sell side), since the call is singular not plural, to me it implies get one orderbook (eg MSC/PROP or PROP/MSC rather than both, both could get confusing).

Thanks Zathras

[ghost]

I tried to stay close to the implementation's understanding of things when writing getorderbook_MP, but more than open to changing it to something that makes more sense. ATM, the properties are interpreted as getorderbook_MP(owned_prop, desired_prop) which is a part of the help text

1. I think this seems intuitive enough, but not any more so than the current scheme
2. If there's two properties in the new scheme, the second property just acts as an additional filter for the book, showing orders with both properties that are on either side that match

[dexX7]

An orderbook is usually a list of buy and sell orders. Given that there is basically no differentiation between buy and sell orders in the current model, I think it would make sense that getorderbook_MP(property1, property2) and getorderbook_MP(property2, property1) return a similar result.

I see the point of returning only "one side", if getorderbook_MP is called with one value. In this case it's basically getorderbook_MP(propertyA) -> "get all orders that offer propertyA". For completeness there might be an complement of "get all orders that desire propertyA".

showing orders with both properties that are on either side that match

I would welcome this. It also mirrors the behavior of gettradessince_MP.

[dexX7]

This seems to be a question of semantics, and material for https://github.com/OmniLayer/omnicore/issues/9.