Use Cases
- Expose the Interpreter REPL interface
- Accept a Rholang text file for evaluation by the interpreter, validate that the file contains text only, and then pass the contents of the file to the Interpreter.
- Throw an error if the file contains non-text data.
- Return the results of evaluation.
- Must provide backward and forward compatibility (please implement using Google protocol buffers (gRPC Service)
- Bond as a validator in a namespace
- Unbond from a namespace
- Return the bond amount given a purse id (need to check if there is a purse id that can be passed in - and if this is secure)
- Return the rewards for a given date range
- Return a block given its hash
- Return the code at a given block hash and address
- Create a transaction
Design Considerations
- The API must not accept files directly, as this presents a security risk.
Interfaces
Describe how the software will interface with other software components.
System Interface
TODO - sort this section out.
Hardware Interface
Describe how the software will interface with physical systems, ex: ports for communication, which devices are to be supported and any hardware protocols used.
Software Interface
Will software be used in creating the system? If so, indicate what software (name and version), how it is to be used, and any details about how it interfaces with the software being specified.
User Interface
What is the user interface for the software? How will users interact with the software? List out all the aspects involved in making the UI better for all users that will interact or support the software.
Communications Interface
System Overview
Provide a description of the software system, including its functionality and matters relating to the overall system and design. Feel free to split this up into subsections, or use data flow diagrams or process flow diagrams.
Limitations
Assumptions and Dependencies
Architectural Strategies
Describe any design decisions and/or strategies that affect the overall organization of the system and its higher-level structures. These strategies should provide insight into the key abstractions and mechanisms used in the system architecture. Describe the reasoning employed for each decision and/or strategy (possibly referring to previously stated design goals and principles) and how any design goals or priorities were balanced or traded-off. Such decisions might concern (but are not limited to) things like the following:
- Use of a particular type of product (programming language, database, library, etc. ...)
- Reuse of existing software components to implement various parts/features of the system
- Future plans for extending or enhancing the software
- User interface paradigms (or system input and output models)
- Hardware and/or software interface paradigms
- Error detection and recovery
- Memory management policies
- External databases and/or data storage management and persistence
- Distributed data or control over a network
- Generalized approaches to control
- Concurrency and synchronization
- Communication mechanisms
- Management of other resources