Skip to content
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

[ENHANCEMENT PROPOSAL] Account Info Standard Support #10

Open
GuybrushX opened this issue Oct 31, 2023 · 0 comments
Open

[ENHANCEMENT PROPOSAL] Account Info Standard Support #10

GuybrushX opened this issue Oct 31, 2023 · 0 comments

Comments

@GuybrushX
Copy link

Summary

Add support for the Account Info Standard in the .Net SDK clients library to ease the process of retrieving account information.

Motivation

The lack of built-in support for the Account Info Standard in the .Net SDK makes it cumbersome to retrieve that information. Providing a streamlined method would enhance the SDK's utility.

Guide-level explanation

  • Introduce a new class or method in the client library to handle Account Info Standard operations.
  • Example usage would involve calling this new method to either fetch a URL to the JSON file or a type-safe wrapper around the JSON data.

Reference-level explanation

The new feature could be implemented in the clients library as a contract client. Two modes could be supported:

  1. A simple mode where the client is provided a URL to the JSON file or update it to a new URL.
  2. A more advanced mode offering a type-safe wrapper around the JSON file.

For contract hashes, these could be stored for MainNet and TestNet but configurable for internal test networks. The file name also has to be set to the chain-spec (casper vs casper-test).

Important Note - would be nice if that could be handled automagically:

Payment: The set_url entry point call payment should be 10 CSPR. The deploy may fail with an "Out of gas" error if a smaller amount provided. For the consecutive set_url calls the advised payment amount is 0.5 CSPR

Source

Drawbacks

This feature could add extra maintenance workload and potential complexity to the clients library.

Rationale and alternatives

  • This design addresses the issue by providing both quick and comprehensive solutions.
  • An alternative is to leave it as-is and require manual handling, which is less efficient.
  • The impact of not doing this is continued manual handling of Account Info Standard.

Unresolved questions

  • Should the contract hashes for internal test networks be passed as optional parameters?

Future possibilities

  • Add a Validation-utility using the existing JSON Schema
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant