clearmatics / ion-cli Goto Github PK
View Code? Open in Web Editor NEWCommand line interface for Ion Protocol
License: GNU General Public License v3.0
Command line interface for Ion Protocol
License: GNU General Public License v3.0
The CLI should follow the company SDLC framework.
Acceptance criteria:
Each new version of the CLI must be:
CHANGELOG
fileFurthermore, a command or a flag (i.e. version
or -v
) must easily tell the user which version he's currently using.
The current functionality allows users to manually perform interactions with the chain and passing of proofs and blocks.
To make the CLI more usable, we should allow a simple Ion layer that abstracts away the complexities of each step through simple commands like:
These commands should fetch necessary data from source and submit to a destination.
We can allow more advanced users who require finer control to access the full set of commands by enabling 'advanced mode' during start up or runtime which exposes the full set of commands.
As a user of the CLI, I'd like to have autocompletion enabled, especially for arguments (i.e. file paths)
Currently contract compilation works by supplying Solidity source code. This creates a contract instance that enables direct interaction with the contract functions.
We should be able to create contract instances without source code.
What other things would be necessary to facilitate this?
We require bytecode in order to actually build the contract instance.
We require abi in order to correctly decode the structure of the bytecode into named functions for interaction.
As a user, i would like to retrieve the contract interface passing a contract name (that in turn is associated internally to its address - issue). This would help to submit message calls towards the smart contract.
As part of the cli refactoring, we need to logically define boundaries of three vital components of the app to abstract a lot of the redundancy in commands from the user. The goal here is to create a sense of statefulness (while under the hood each call is stateless) in the application so that to reduce the amount of flags and args on the commands. This may be achieved with:
Config: json object that keeps the whole set of configuration info, like accounts map[string]{keyfile, password}
, networks map[string]{clientURL, gasPrice}
, contracts map[string]{ solFile, abi
} and so on. This will be populated with commands like: ion-cli accounts/network add [args]
For each cli call, the whole set of configs is automatically parsed into the viper object and operations on it will be done through viper APIs.
Profile: subset of config keys the user sets as default under a specific profile. The profile obj is structured in semantic concepts that are higher level and increase usability. For example a profile could group configs into chains object
profiles map[string]{
chains: map[string] {
network string,
accountName string,
contracts : {tbd},
--------- plus other data that might be cached throughout calls like
lastBlock, lastIonProof
}
}
The profile object won't hold the configs, but only the keys that reference the specific config object in the viper set. All the profiles will be stored in a file like profile.json
. At this point just by passing the profile name on a command the app would be able to derive all the configs needed to make the call go through.
Just by something like ion-cli session init --profileName
the user will then be able to interact with ION through high level commands like ion submitBlock from chainA to chainB
.
This of course allows to prioritize the cli layer to fetch the needed configs:
Flags related to configs will only represent keys to grab the specific value from viper and this hopefully will shorten the commands.
P.S.
The separation between configs and profiles is subtle and might be actually condensed into a single layer, we should discuss pros and cons of having them. Definitely the separation of concerns allow for example to shuffle configs into different profiles, without the need to copy the values.
As a user of the cli, i don't want to care about contract addresses and other low level info, rather I'd like to call contract functions using the contract name.
The contract-instance object should keep track of the deployed address and internally use it.
Futhermore, user should have the ability to set the contract address associated with a name.
As a user of the cli, I would like to input just once my key file and contracts to be used, and not for each new session.
Furthermore, I should have the possibility to re-set them as needed.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.