Scetch a possiblity for custom logic in the broker

[flxo]

Use the authentication stuff as an example how customer code could be plugged into the broker. The authentification is not implemented - it's all just about how to proceed...

The concrete type that impls the authentication has the advantage of static dispatch. There ware probably other traits needed for intercepting publishes and subscriptions e.g

pub trait {
  async fn on_publish(client_id: &str, publish: &PublishPacket) -> PublicationResult;
  ....
}


Do *not* merge this :-)

[flxo]

@bschwind a quick attempt how to plug custom logic into the broker - no logic implemented - just to get the discussion started. Thanks for comments!

[bschwind]

Hey @flxo, sorry for the late response! Been on holiday the past week, but I'll try to take a look at this soon.

[flxo]

@bschwind Thanks!

[bschwind]

@flxo thanks for the work so far! I saw you originally were using async trait methods (via the async-trait crate), what was your reasoning for switching away from it?

It's not that I'm for or against it, just curious about the reasoning. I think that will be a big decision for us - do we want to allow async operations in the plugins? I can imagine a plugin that would want to read from a database or key-value store before making a decision, so it might be nicer to have the functions be async. I haven't thought through all the implications yet.

I looked less at the logic changes in broker.rs as I think settling on the API design first is important.

I left some more targeted comments in the code itself. Thanks again!

[bschwind]

What's the reasoning for splitting out publishes based on the qos? PublishPacket already has the qos field on it, but maybe there's some other reasoning for it that I'm missing.

Is this for handling the individual steps in the QoS sending handshake, or just a wholesale "We received a qos2 packet, do you want to send it?"

[flxo]

I had a single "callback" for publication but struggled with the return type. There's no return for QOS0, a Publish Ack for QOS1 and PublishReceivedAck for QOS2.
I'm fine with merging those if you want and but would require to define a struct for that the includes basically the same as the PublishAckPacket and PublishReceivedPacket in an Option.

[flxo]

@flxo thanks for the work so far! I saw you originally were using async trait methods (via the async-trait crate), what was your reasoning for switching away from it?

It's not that I'm for or against it, just curious about the reasoning. I think that will be a big decision for us - do we want to allow async operations in the plugins? I can imagine a plugin that would want to read from a database or key-value store before making a decision, so it might be nicer to have the functions be async. I haven't thought through all the implications yet.

I looked less at the logic changes in broker.rs as I think settling on the API design first is important.

I left some more targeted comments in the code itself. Thanks again!

The reason why I used the async-trait thing is because I need exactly what you described: query an eternal entity where I have a client for that also uses tokio and provides async fn. I haven't look into cool ways to call async code from sync without channels in between.

I will try to answer your findings inline.

[bschwind]

@flxo still keeping an eye on this PR! Sorry though that I don't have the bandwidth for quick reviews. I'll be happy to give it a look when you think it's ready for another review.

[flxo]

@flxo still keeping an eye on this PR! Sorry though that I don't have the bandwidth for quick reviews. I'll be happy to give it a look when you think it's ready for another review.

Thanks. I'll try to solve some of the todos I left in the PR and will ping you.

[flxo]

@bschwind I refactored the connection handling a bit and separated the unauthenticated connections from the session. Introduced a ConnectionId which is a unique identifier for a connection.

I'd love to hear your feedback.

[bschwind]

Hi @flxo

Sorry for the long time radio silence. I still think this is good work, but I don't have enough bandwidth to review this in any sort of timely fashion.

I plan to get back into this project around the time when I update my ESP32 projects to use Rust, but until then you probably won't see too much activity from me on it. I would recommend working with either your fork of this repo, or rumqtt (which I would guess is farther along and has more contributors)