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

extract ABI primitives from near-sdk #1

Merged
merged 12 commits into from
Aug 23, 2022
Merged

extract ABI primitives from near-sdk #1

merged 12 commits into from
Aug 23, 2022

Conversation

miraclx
Copy link
Contributor

@miraclx miraclx commented Aug 16, 2022

Exports the ABI primitives from SDK.

Copy link
Contributor

@itegulov itegulov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yet to look at the changes, but one thing I want to point out is that I would personally prefer this repo to be something more generic like near-abi-schema that will at some point contain meta schema, README explaining what ABI is and all "official" model implementations (crate + npm package for now). What do you think?

@miraclx
Copy link
Contributor Author

miraclx commented Aug 16, 2022

Yeah, we can do that. I'm just thinking this will be the repo that contains the official rust implementation of said schema. We can go ahead to create the near-abi-schema and have this repo bound to that. But if you think the near-abi-rs name is too broad for this case, we can consider alternatives.

src/lib.rs Outdated
Comment on lines 62 to 70
/// Core ABI information, with schema version.
#[cfg(feature = "versioned-entries")]
#[derive(Clone, Debug, Serialize, Deserialize, PartialEq)]
pub struct VersionedAbiEntry {
/// Semver of the ABI schema format.
abi_schema_version: String,
#[serde(flatten)]
pub abi: AbiEntry,
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea of statically known versions, but I wonder if there is a better way to represent this. Have you thought about something like this (very roughly outlined)?

pub enum VersionedAbiEntry {
    #[serde(rename = "0.1")]
    V0_1(AbiEntryDeprecated),
    #[serde(rename = "0.2")]
    V0_2(AbiEntryDeprecated),
    #[serde(rename = "1.0")]
    V1_0(AbiEntry),
}

And then change abi.json to look like this:

{
  "metadata": {
    "name": "abi",
    "version": "0.1.0",
    "authors": [
      "Near Inc <hello@nearprotocol.com>"
    ]
  },
  "1.0": {
    ... // AbiEntry contents
  }
}

I never liked that abi.json has a field named abi, so maybe it is time to change it? :)

Copy link
Contributor Author

@miraclx miraclx Aug 18, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's this? ... Okay I like it, Picasso. 1

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only thing I'd think about this, is that supporting the different types might be awkward to work with. Seems like the version should be based on the whole schema, rather than just the ABI section, maybe. Would match JSON schema more closely. Supporting this would be straightforward in Rust, but unclear how this would work well with JS/TS or other languages without enums like this

src/lib.rs Outdated Show resolved Hide resolved
@itegulov
Copy link
Contributor

Yeah, we can do that. I'm just thinking this will be the repo that contains the official rust implementation of said schema. We can go ahead to create the near-abi-schema and have this repo bound to that. But if you think the near-abi-rs name is too broad for this case, we can consider alternatives.

I was just thinking that it would be better to have all schema models in one place since they will probably be rather small and depend on the metaschema (TBD) in some way. Not a big deal either way, just expressing an opinion.

@miraclx miraclx mentioned this pull request Aug 21, 2022
src/lib.rs Outdated Show resolved Hide resolved
src/private.rs Outdated Show resolved Hide resolved
src/private.rs Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
Cargo.toml Show resolved Hide resolved
[dependencies]
borsh = { version = "0.9", features = ["const-generics"] }
serde = { version = "1", features = ["derive"] }
schemars = "0.8.8"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noting the unfortunate circumstance that if someone didn't want any JSON schemas in their ABI, this dependency still gets pulled in to every project (including near-sdk if the abi feature is enabled). Nothing has to change here, just mentioning

Copy link

@austinabell austinabell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

approving because none of my comments are blocking, but @itegulov might have some other comments

@miraclx miraclx requested a review from itegulov August 23, 2022 03:31

for entry in entries {
if let Some(ref schema_version) = schema_version {
// should probably only disallow major version mismatch
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In theory the version mismatch should not happen at all, since they are all pulled from the same crate. So not sure if it makes sense to bother with distinguishing major/minor versions.

@miraclx miraclx merged commit 4844ef4 into master Aug 23, 2022
@miraclx miraclx deleted the miraclx/init branch August 23, 2022 06:47
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

Successfully merging this pull request may close these issues.

3 participants