[DRAFT] statement-store: re-defining RPC API surface

[alexggh]

Taking a stab at making the API surface easier to understand and complete for the required use cases.

Proposal

• Introduce a subscription API with filtering only on topics, removed the ability to query statements since subscription is the desired model and anything achievable with the query can be achieved with the subscription as well.
• Rename priority in expiry, make it mandatory and define what it contains, the most significant 32 bits represent the expiration time(in seconds since UNIX epoch) and the lower 32 bits represent an arbitrary sequence number used to order statements with the same expiration time.
• Document how statements fields like channel_id and expiry interact.

TODO

• [WIP] Implement API's: [DRAFT] statement-store: implement new api #10690
• Tests

[ERussel]

Just to confirm the logic, am i right that this endpoint immediately provide currently matching statements and then send new matching statement once they appear in the store? Also if the current number of statements is too big will it automatically split them into pages the return in the separate updates?

[alexggh]

Just to confirm the logic, am i right that this endpoint immediately provide currently matching statements and then send new matching statement once they appear in the store?

Yes, the plan is to immediately provide currently matching statements.

Also if the current number of statements is too big will it automatically split them into pages the return in the separate updates.

Not sure I understand why would you need pagination for the subscribe, you would receive each statement one by one.