split crate into core and async

[kujeger]

Hi,

I realize this is a bit big of a thing out of the blue, but I was playing a little around with creating a kind of rnsd-rs, and realized it would be easier and neater if reticulum-rs didn't come with as much tokio baggage out of the box, and got a little carried away 😅 .

Is this a direction you want to go? It makes a lot of sense to me -- split the core stuff out into a core crate and remove tokio/async dependencies in it, and keep the interface management etc in the main/async crate. Should also make it easier for future embedded use cases.

The main thing done here that isn't just a straight move is abstracting the broadcast channel in link.rs into a LinkEventSink trait, that the main crate's transport.rs implements using tokio::sync::broadcast::Sender

[doubleailes]

It can be a good idea to move all the crates under a crates folder.
And simplify the config in config.toml by members = ["crates/*"]

[spearman]

It can be a good idea to move all the crates under a crates folder. And simplify the config in config.toml by members = ["crates/*"]

I don't think that's idiomatic (compare the tokio, rand, and serde crates that all list workspace members explicitly), I would prefer to avoid the extra subdirectory. If we really don't want to list the workspace members manually members = ["reticulum-*"] will also work, but I think they should be explicitly listed.

[kujeger]

Yeah, I would prefer not to introduce additional subdirectories. I also second the belief that current approach here is the most idiomatic and matches all the other "big" crates I've seen.

Being able to do ["foo-*"] in the workspace list is neat though, I've never thought of that before, so thanks for pointing that out! But unless we somehow end up with a very large amount of crates I think it's just as well to list them explicitly.

[kujeger]

@n-beechat do you folks have any thoughts on this kind of (re-)structuring of reticulum-rs ?