refactor: protocols rather than Rust-specific implementations in abstraction names

[maksimryndin]

I am following Miden tutorials, specifically the initial client setup) and for a rpc it uses

use miden_client::rpc::TonicRpcClient;
...

let rpc_api = Arc::new(TonicRpcClient::new(&endpoint, timeout_ms))

...

I would suggest renaming TonicRpcClient to GrpcRpcClient (or simply GrpcClient) to be agnostic to language-specific things for future uniformity with clients in other languages (ideally, in future all abstractions across implementations should be mapped 1-1) and to highlight a "transport" protocol (e.g. grpc, jsonrpc etc) rather than a specific implementation (namely, tonic crate).

[bobbinth]

I like GrpcClient. @igamigo, @partylikeits1983 what do you think?

Also, separate but related thought - should we break out complete Client PRC implementations into separate crates? Maybe something like miden-client-rpc and miden-client-web-rpc? I'm trying to think of a way to get rid of the mutually exclusive tonic and tonic-web features - though, maybe that's not the best way.

[igamigo]

I don't specifically mind TonicRpcClient, there's some value in specifiying this is tonic-based IMO. But also I don't mind GrpcClient either, so should be fine to change.

Also, separate but related thought - should we break out complete Client PRC implementations into separate crates? Maybe something like miden-client-rpc and miden-client-web-rpc? I'm trying to think of a way to get rid of the mutually exclusive tonic and tonic-web features - though, maybe that's not the best way.

I think we discussed this at some point and it could make sense to have separate crates for the RPC client. Although for removing the features specifically, we might be able to do something like what we do in the proving service client crates to work on both WASM and std environments.

[partylikeits1983]

I agree with this suggestion. Renaming TonicRpcClient to GrpcRpcClient or GrpcClient would indeed enhance future uniformity across different language implementations. Focusing on the transport protocol rather than a specific crate like Tonic aligns well with broader design principles.

[tomyrd]

Should the same be done for SqliteStore which contains it's specific implementation name? Some alternate names could be SqlStore, FileStore or NativeStore (maybe it's too generic).

[bobbinth]

I think for the store it may be a bit tricky because, for example, there could be different SQL-based backends (technically possible for gRPC too - but much less likely given that tonic is by far the most popular option). Same goes for web options.

[maksimryndin]

For SqliteStore it should be less a problem as Sqlite has bindings in all mainstream languages.