feat(demo): add AVMProvider #20
Conversation
PhearZero
force-pushed
the
feat/avm-provider
branch
from
f384944 to
0caba97
Compare
|
|
||
| // Must be unique to this provider | ||
| val providerId = uuidGenerator.generate().toString() | ||
| private val provider = AVMProvider(providerId) |
There was a problem hiding this comment.
The AVMProvider is being imported from demo and we are creating the class in the demo package.
Can't we just import the actual package and use that?
There was a problem hiding this comment.
We could offer a base interface with empty stubs or go with a more advanced strategy. The wallets would need to handle the signing operations and anything extra like Bio-metrics. We only are dependent on the message shapes/encoding at this point
| } | ||
| } | ||
| // TODO: Refactor to ByteArray and allow streaming of the Buffer | ||
| val resultMessage = provider.handleRequestMessage(Message(Base64.UrlSafe.decode(msgStr), EncoderType.CBOR), keyPair) |
There was a problem hiding this comment.
handleRequestMessage should probably be from an agnostic interface that any AVM / Identity / other context can implement so that. Can we do that? Should be straight forward; maybe the interface can live in liquid code package
There was a problem hiding this comment.
Should be that way now, it does accepts a generic Message which is only the bytes and the encoding (not specifying ARC27 schema).
I named the method handleRequestMessage since it only handles RequestMessages from ARC27 (the most common use case for the Wallet and the AVMProvider). I could refactor it to handleMessage and have it support both?
| * A provider for the Algorand Virtual Machine (AVM). | ||
| * Used to test the provider.avm.models package. | ||
| */ | ||
| class AVMProvider(val providerId: String) { |
There was a problem hiding this comment.
This class should be part of the provider package?
There was a problem hiding this comment.
In continuing with #20 (comment), there are a few ways we could make this generic with a BaseProvider. It was included before we simplified, possibly it was over simplified?
I couldn't find a good shape that was useful outside of Observables, since we don't depend on the providers shape or interacting with multiple providers in a single application. It made sense to just make a concrete example of using the Models directly.
Example Base:
enum class EncoderType {
MSGPACK,
BASE64,
CBOR,
NONE
}
interface IMessage {
payload: ByteArray
encoding: EncoderType
}
interface IBaseProvider {
fun handleMessage(message: IMessage): Any
}There was a problem hiding this comment.
Lets to this! And the base interfaces can live in the liquid core package. Thanks !
ℹ Overview
cryptolibrary in favor of Algo ModelsBlocked By
📝 Related Issues
✅ Acceptance: