You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During the WASM32-Binding development, generic parameters have been introduced on the wasm32-develop branch to abstract away platform specific adapter types used in our platform agnostic Identity code.
Example: IdentityClient<S, C: Clone, M: Send> where the generic parameter M abstracts away the platform specific AssetMoveCalls or IdentityMoveCalls.
These generic parameters have been introduced to avoid circular dependencies. The new generic parameters led to several new problems with Send and Sync trait constraints. We needed to address these problems by feature switches which increased code complexity and efforts a lot.
Task Description
The dependency structure between the Identity crates needs to be redesigned so that circular dependencies can be avoided without the need for generic parameters.
Following modules need to be located in new or existing crates:
identity_iota_interaction
Formerly known as iota_sdk_abstraction. Trait definitions and a wasm32 compatible subset of code, copied from IOTA Client Rust SDK, used to replace the IOTA Client Rust SDK for wasm32 builds.
iota_interaction_ts
Formerly known as ts_sdk_adapter. Imports Typescript IOTA Client SDK types using wasm-bindgen generated wasm bindings
and implements identity_iota_interaction traits (among others, IotaClient and MoveCall traits) for wasm32 platforms.
iota_interaction_rust
Formerly known as rust_sdk_adapter. Implements identity_iota_interaction traits for the NON wasm32 platforms using the IOTA Client Rust SDK
identity_iota_core/src/rebased
Implements the IdentityClient for IOTA Rebased using iota_interaction_rust or iota_interaction_ts depending on the build platform
identity_wasm
Exports the IdentityClient to Typescript using wasm-bindgen generated wasm bindings
Following diagram visualizes a proposed structure for the Identity crates and folders. The structure needs to be discussed before starting this task:
The folder structure to locate the above shown crates and folders, would look like this:
bindings
wasm
identity_wasm - Crate
Contains the existing identity_wasm crate currently located in bindings/wasm.
iota_interaction_ts - Crate
identity_iota_interaction - Crate
The import path inside the identity_iota_core::rebased module would be 'identity_iota::iota_interaction'.
identity_iota_core - Crate
src
rebased
The import path for the iota_interaction_rust resp. iota_interaction_ts would be 'crate::iota_interaction_adapter'.
The import path for the IOTA Client Rust SDK resp. identity_iota_interaction would be 'identity_iota::iota_interaction'.
iota_interaction_rust
There would be no new crate for iota_interaction_rust.
The folder iota_interaction_rust contains the adapter code as described above.
The module is not accesses directly but via the iota_interaction_adapter (see below.)
iota_interaction_adapter.rs
Contains platform specific compile switches, managing the import module paths for iota_interaction_rust and iota_interaction_ts.
The text was updated successfully, but these errors were encountered:
chrisgitiota
added
Rust
Related to the core Rust code. Becomes part of the Rust changelog.
Wasm
Related to Wasm bindings. Becomes part of the Wasm changelog
labels
Nov 25, 2024
The chosen names are just ideas. To brain storm on folder names, the following tables lists some more ideas for folder and crate names.
Regarding the naming some constraints should be matched:
The identity_iota_<INTEGRATION_DESCRIBER> crate needs to use the identity_iota prefix
The implementations of the identity_iota_<INTEGRATION_DESCRIBER> traits should also use the <INTEGRATION_DESCRIBER> with a rust or ts prefix or postfix
Here are the tables with folder and crate name ideas. Feel free to add more ideas. Crate names are marked with bold style:
Context
During the WASM32-Binding development, generic parameters have been introduced on the
wasm32-develop
branch to abstract away platform specific adapter types used in our platform agnostic Identity code.Example:
IdentityClient<S, C: Clone, M: Send>
where the generic parameter M abstracts away the platform specific AssetMoveCalls or IdentityMoveCalls.These generic parameters have been introduced to avoid circular dependencies. The new generic parameters led to several new problems with
Send
andSync
trait constraints. We needed to address these problems by feature switches which increased code complexity and efforts a lot.Task Description
The dependency structure between the Identity crates needs to be redesigned so that circular dependencies can be avoided without the need for generic parameters.
Following modules need to be located in new or existing crates:
identity_iota_interaction
Formerly known as
iota_sdk_abstraction
. Trait definitions and a wasm32 compatible subset of code, copied from IOTA Client Rust SDK, used to replace the IOTA Client Rust SDK for wasm32 builds.iota_interaction_ts
Formerly known as
ts_sdk_adapter
. Imports Typescript IOTA Client SDK types using wasm-bindgen generated wasm bindingsand implements identity_iota_interaction traits (among others, IotaClient and MoveCall traits) for wasm32 platforms.
iota_interaction_rust
Formerly known as
rust_sdk_adapter
. Implements identity_iota_interaction traits for the NON wasm32 platforms using the IOTA Client Rust SDKidentity_iota_core/src/rebased
Implements the IdentityClient for IOTA Rebased using
iota_interaction_rust
oriota_interaction_ts
depending on the build platformidentity_wasm
Exports the IdentityClient to Typescript using wasm-bindgen generated wasm bindings
Following diagram visualizes a proposed structure for the Identity crates and folders. The structure needs to be discussed before starting this task:
The folder structure to locate the above shown crates and folders, would look like this:
identity_wasm
- CrateContains the existing identity_wasm crate currently located in
bindings/wasm
.iota_interaction_ts
- Crateidentity_iota_interaction
- CrateThe import path inside the
identity_iota_core::rebased
module would be 'identity_iota::iota_interaction'.identity_iota_core
- Craterebased
The import path for the
iota_interaction_rust
resp.iota_interaction_ts
would be 'crate::iota_interaction_adapter'.The import path for the
IOTA Client Rust SDK
resp.identity_iota_interaction
would be 'identity_iota::iota_interaction'.iota_interaction_rust
There would be no new crate for
iota_interaction_rust
.The folder iota_interaction_rust contains the adapter code as described above.
The module is not accesses directly but via the iota_interaction_adapter (see below.)
Contains platform specific compile switches, managing the import module paths for
iota_interaction_rust
andiota_interaction_ts
.The text was updated successfully, but these errors were encountered: