search

proman21 / tokio-mqtt

Rust MQTT Client written with tokio
7 stars 1 forks source link

Timeframe #1

Open drahnr opened 6 years ago

drahnr commented 6 years ago

Over the weekend I dug into the code and I am interested in pushing this further and I'd like to know what your plans are (besides filling the unimplemented!() blocks) and in what time frame so I am not going to duplicate your efforts. Which actor library are you working on btw?

proman21 commented 6 years ago

Thanks for the interest. Right now the project is on hiatus because a) I'm in uni semester, and b) I'm putting my efforts into a actor system for Rust. Right now the logic that reads and writes and manages state is an awful mess because I'm refactoring constantly to try and overcome issues in the code. Once the actor system is ready, I'll be transitioning the backend to an actor model style of concurrency. This should solve a lot of the issues with mutable state, state transitions and ownership that have been making it a lot harder. I might write up a little roadmap on the wiki so people can see what the deal is.

drahnr commented 6 years ago

Could you maybe spare a few minutes to add a few extra comments? That would help me a lot since I need this rather short term :) so I can not wait for the actor system, but I am happy to migrate later on!

drahnr commented 6 years ago

Which License did you intend to publish this under? I would love to publish this under MIT/Apache-2.0 I got a basic version compiling and I will do some testing tomorrow/next week.

proman21 commented 6 years ago

I'm gonna publish it as Apache/MIT. Currently I found an actor library I like and I'm gonna rebuild this with that.

drahnr commented 6 years ago

Alright. I will continue digging into the current implementation.

One question: What was the motivation behind using individual structs over using enums given the set of headers is a complete?

proman21 commented 6 years ago

Enum destructing was adding a lot of unnecessary code like this.

let id = match headers.get("packet_id") {
    Header::PacketId(id) => id,
    _ => unreachable!()
}

It was nicer to allow the type system do the work of validating the data. I borrowed the high-level concept from hyper in how it allows access to HTTP headers.