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
First, sorry to open PR(#15, #16) before this issue, and thanks for this crate, such that we can have a channel to talk to each other. I will list down the details here before the bi-week meeting starts just to make sure I will not miss out on some detail and do not mean on this (I live in the +8 timezone, and the time of the meeting is midnight), and you do not need to hurry to respond this if you are busy.
Real Use Case
An application uses LiquidityManager, which has LSPS0MessageHandler in it.
Now lsps0.listprotocols is implemented inside, it is good to request the application(release build) and make sure it works to validate the application before delivery.
So anything under #[cfg(test)] or unit test will not solve, because every byte in #[cfg(test)] or unit test is not really in the release build binary. I do integrate and do not have the duty of developing this repo, contributing to test cases, or any kind of unit test that does not make sense from my end and does not solve my issue on validating the release binary.
The Way to Receive Response in Blockchain
This is the part I really confuse in this project. In General, the response of blockchain sends out in two ways, it is hard to know how it will be in the current project. Different blockchains may use different names, and the basic mechanism are these.
Directly Response (like HTTP, RPC, or JSON RPC, etc whatever)
Blockchain Node <-----> Queryer (possibly a Node, client, or cli, etc whatever)
For the direct response, the function actually handles the content of the request and will return the content of the response.
Broadcast Response to the Blockchain Network (like Event, etc)
Blockchain Node <-----> Blockchain Node (Queryer, also a blockchain node to receive Event)
|
\-----------> Blockchain Node
\-----------> Blockchain Node
\-----------> Blockchain Node
....
In this way, the response or event will send to every node. There are three ways a query can know the exact response to his request.
The content is a status or a general thing (No additional Id)
take the lsps0.listprotocols as an example
If there is a field to represent the node, then we can use this, the current spec of lsps0 is not
{
"node_id": "0xAAAAA",
"protocols": [0]
}
With request Id or receipt Id
There is an id in the response, and commonly any other things are in a result field like this(nesting is not necessary). Because of the id, the queryer can listen the events and know which one is the response to the request he sent.
{
"id": "let the query know this is for him",
"result": {
"protocols": [0]
}
}
And there are two kind Id of this based on the mechanism wherein who generate the id
the Id is generated by queryer, normally it is named request Id
The request Id will be defined as a required field in the request
the Id is generated by node receiving the request, normally it is named receipt Id
The receipt Id will return to the queryer as a directly response, this means the handler will return an Id but not the response itself.
Currently Status and Issues
The corresponding functions return Result<(), _>.
The id is generated in the handler, and it is called RequestId
There is no function in LiquidityManager to make a request to other node or self node
Terminology
The application with LSPS will handle any incoming LSPS message and also send LSPS messages out, so the term Client or Server I try to avoid. It mixes two kinds of roles. And there is still a difference between an application listening to the event and not. So the term Node means it is in the blockchain network and will listening events or broadcast events.
The text was updated successfully, but these errors were encountered:
Hi there,
First, sorry to open PR(#15, #16) before this issue, and thanks for this crate, such that we can have a channel to talk to each other. I will list down the details here before the bi-week meeting starts just to make sure I will not miss out on some detail and do not mean on this (I live in the +8 timezone, and the time of the meeting is midnight), and you do not need to hurry to respond this if you are busy.
Real Use Case
So anything under
#[cfg(test)]
or unit test will not solve, because every byte in#[cfg(test)]
or unit test is not really in the release build binary. I do integrate and do not have the duty of developing this repo, contributing to test cases, or any kind of unit test that does not make sense from my end and does not solve my issue on validating the release binary.The Way to Receive Response in Blockchain
This is the part I really confuse in this project. In General, the response of blockchain sends out in two ways, it is hard to know how it will be in the current project. Different blockchains may use different names, and the basic mechanism are these.
For the direct response, the function actually handles the content of the request and will return the content of the response.
In this way, the response or event will send to every node. There are three ways a query can know the exact response to his request.
The content is a status or a general thing (No additional Id)
take the
lsps0.listprotocols
as an exampleIf there is a field to represent the node, then we can use this, the current spec of lsps0 is not
With request Id or receipt Id
There is an
id
in the response, and commonly any other things are in a result field like this(nesting is not necessary). Because of theid
, the queryer can listen the events and know which one is the response to the request he sent.And there are two kind Id of this based on the mechanism wherein who generate the id
The request Id will be defined as a required field in the request
The receipt Id will return to the queryer as a directly response, this means the handler will return an Id but not the response itself.
Currently Status and Issues
Result<(), _>
.LiquidityManager
to make a request to other node or self nodeTerminology
The application with LSPS will handle any incoming LSPS message and also send LSPS messages out, so the term
Client
orServer
I try to avoid. It mixes two kinds of roles. And there is still a difference between an application listening to the event and not. So the termNode
means it is in the blockchain network and will listening events or broadcast events.The text was updated successfully, but these errors were encountered: