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
Pangea needs a lot of custom calls to fetch initial state from panthalassa. For example:
identity public key
chat messages
and much more (specially in the future)
Writing a method for fetching all of those data is very time consuming since we have to build bridges for ios and android. A dynamic "call" module would fix that problem. The dynamic call module will take a call id (e.g. MESSAGES) as the first parameter and an map of values as the second parameter (e.g. {chat: "partner-id-pub-key", amount: 50}). The call will then be validated by the module and fetch the messages based on the parameters. A call module should always return an map of values. There should be a call module interface and a call module registry, the registry would basically take care of finding the right module for a call id.
This is how the call module might look like:
typeCallModuleinterface {
// the call id this module relates to CallID() string// validate the given parameters - might return an error when received invalid parametersValidate(map[string]interface{}) error// will handle the call and return the resultHandle(map[string]interface{}) (map[string]interface{}, error)
}
This is how the call module registry might look like:
Feature / Issue
Pangea needs a lot of custom calls to fetch initial state from panthalassa. For example:
Writing a method for fetching all of those data is very time consuming since we have to build bridges for ios and android. A dynamic "call" module would fix that problem. The dynamic call module will take a call id (e.g.
MESSAGES
) as the first parameter and an map of values as the second parameter (e.g.{chat: "partner-id-pub-key", amount: 50}
). The call will then be validated by the module and fetch the messages based on the parameters. A call module should always return an map of values. There should be a call module interface and a call module registry, the registry would basically take care of finding the right module for a call id.This is how the call module might look like:
This is how the call module registry might look like:
You are free to come up with other ideas / solutions. Please just post them here in the GH issue.
Acceptance criteria
The text was updated successfully, but these errors were encountered: