rust-libp2p/examples/distributed-key-value-store/Cargo.toml

[package]
name = "distributed-key-value-store"
version = "0.1.0"
edition = "2021"
publish = false
license = "MIT"

[dependencies]
async-std = { version = "1.12", features = ["attributes"] }
async-trait = "0.1"
env_logger = "0.10"
futures = "0.3.28"
libp2p = { path = "../../libp2p", features = ["async-std", "dns", "kad", "mdns", "noise", "macros", "tcp", "websocket", "yamux"] }
multiaddr = { version = "0.17.1" }
refactor: move examples to common location Refactor examples into separate binary crates. Fixes https://github.com/libp2p/rust-libp2p/issues/3111. Pull-Request: #3509. 2023-03-08 16:17:33 +08:00			`[package]`
			`name = "distributed-key-value-store"`
			`version = "0.1.0"`
			`edition = "2021"`
			`publish = false`
chore: move `libp2p` crate to a dedicated directory Currently, our top-level `Cargo.toml` manifest represents a crate AND a workspace. This causes surprising behaviour (e.g. #2949) where we need to explicitly pass `--workpace` to every command to run it on the entire workspace and not just the meta crate. My moving the meta crate into its own directory, the root manifest file is a virtual manifest only and thus, every `cargo` command will automatically default to running on the entire workspace. On top of this, I personally find it easier to understand if workspace and crate manifests are not mixed. Pull-Request: #3536. 2023-03-09 00:20:39 +11:00			`license = "MIT"`
refactor: move examples to common location Refactor examples into separate binary crates. Fixes https://github.com/libp2p/rust-libp2p/issues/3111. Pull-Request: #3509. 2023-03-08 16:17:33 +08:00
			`[dependencies]`
			`async-std = { version = "1.12", features = ["attributes"] }`
			`async-trait = "0.1"`
			`env_logger = "0.10"`
deps: bump futures from 0.3.27 to 0.3.28 Pull-Request: #3725. 2023-04-03 14:43:42 +00:00			`futures = "0.3.28"`
feat(libp2p): deprecate mplex `mplex` module (no flow control and no streams limit) is deprecated to encourage `yamux` usage. Resolves #3677. Pull-Request: #3689. 2023-04-04 11:49:59 +02:00			`libp2p = { path = "../../libp2p", features = ["async-std", "dns", "kad", "mdns", "noise", "macros", "tcp", "websocket", "yamux"] }`
feat(swarm): rename associated types for message passing Previously, the associated types on `NetworkBehaviour` and `ConnectionHandler` carried generic names like `InEvent` and `OutEvent`. These names are _correct_ in that `OutEvent`s are passed out and `InEvent`s are passed in but they don't help users understand how these types are used. In theory, a `ConnectionHandler` could be used separately from `NetworkBehaviour`s but that is highly unlikely. Thus, we rename these associated types to indicate, where the message is going to be sent to: - `NetworkBehaviour::OutEvent` is renamed to `ToSwarm`: It describes the message(s) a `NetworkBehaviour` can emit to the `Swarm`. The user is going to receive those in `SwarmEvent::Behaviour`. - `ConnectionHandler::InEvent` is renamed to `FromBehaviour`: It describes the message(s) a `ConnectionHandler` can receive from its behaviour via `ConnectionHandler::on_swarm_event`. The `NetworkBehaviour` can send it via the `ToSwarm::NotifyHandler` command. - `ConnectionHandler::OutEvent` is renamed to `ToBehaviour`: It describes the message(s) a `ConnectionHandler` can send back to the behaviour via the now also renamed `ConnectionHandlerEvent::NotifyBehaviour` (previously `ConnectionHandlerEvent::Custom`) Resolves: #2854. Pull-Request: #3848. 2023-05-14 12:58:08 +02:00			`multiaddr = { version = "0.17.1" }`