-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(token-blueprint): make response messages easier to identify #290
Comments
Great point. Maybe this should be lower-level, so that any message on AO carries a: Or maybe better, if a handler receives something like |
The best way forward is to use When a message is Sent a Reference number is provide, the returning message can send it back using |
@twilson63 This doesn't solve the problem of simplifying the code that identifies what a specific message is about. It's a way to do it, for sure, but the code becomes harder to work with, I think. That's because there are no semantics in the number value from I mean, in a Keep in mind, one of the messages I mentioned in the problem statement is 'Balances' where the response has no semantic tag at all to identify it. Then, this rather ugly "switch"-type handler becomes a necessity.
Maybe there is a better way to do this based on |
@twilson63 I think you suggest using the That's much better in terms of how the code is written, indeed. Sorry for the confusion, I'm looking into applying this now. |
Problem
Response - Type messages have no straightforward way to be matched as such.
e.g.
Info
response is only recognized by the presence of one of the tagsName
,Ticker
,Logo
,Denomination
Balance
response hasBalance
tag ANDData
with the same dataBalances
response has NOBalances
tag, but ONLYData
with the expected dataIt difficult to elegantly implement handlers for all of these responses in the same process, due to the asymmetry (peculiarity) of how the checks need to be performed.
In case of
Balances
it's most extreme, meaning that I can only match aBalances
response by the fact that it has none of the other tags.Solution
Any response-type message be tagged as follows:
This way, responses are matched by
msg.From
as followsNo breaking change
This change is attractive especially since it doesn't break any existing implementations of processes which interact with the token process.
Potentially a good standard
I think this is intuitive to use and could serve as a general pattern for all AO processes. Including it in something as essential as the token blueprint can help in establishing the standard.
The text was updated successfully, but these errors were encountered: