search

0xPolygonMiden / miden-client

Client library that facilitates interaction with the Miden rollup
MIT License
32 stars 28 forks source link

Library API organization #362

Closed bobbinth closed 3 months ago

bobbinth commented 4 months ago

Looking at the Library API docs on docs.rs, I'm thinking we should re-organize the public-facing interfaces. A few specific thoughts below:

  1. Anything that is CLI-specific should probably be moved out of the library. For example, we don't need to have CliConfig there.
  2. I don't think we need the client submodule - instead, we could re-export some of the sub-modules of client at the root level.
  3. In general, we might want to consider a more flat crate organization (in some cases, we have sub-modules with just 1 or 2 components). This does not mean we should change the internal organization - only how things are exported publicly. a. For example, we could have the following modules re-exported from the root: config, errors, rpc, state_sync, store, transactions. And everything else would be either in these modules or at the root level.
  4. We may need to make StoreConfig into an associated type of the Store trait. This is because various store implementations may have different configuration settings.
  5. We should probably create features for controlling exports of various specific trait implementations. For example, we could have sqlite feature which needs to be enabled to export SqliteStore. Similarly, we could have tonic feature for controlling the export of TonicRpcClient.
  6. We should clean up publicly exposed features. For example, I'm not sure if test_utils and uuid need to be stand-alone features. a. Separately, shouldn't concurrent imply std?
mFragaBA commented 4 months ago

point 5 is sort of included in #284

agreed with the other ones.

igamigo commented 3 months ago

Closed by https://github.com/0xPolygonMiden/miden-client/pull/367