Tim

Hm, I'm a little confused about the issue around compliance with the spec. From my perspective, the tarpc transport *is* the MQTT client? MQTT is being used to implement a...

> IF they use an MQTT library that has its own opinion on how to generate a CD (because the spec lets them do that as they desire) Now I'm...

Ok, got it, thanks! Here is the way I'm envisioning this working. - I think it is compliant with the MQTT spec, but please let me know if I'm still...

> I don't follow why you'd want to have two layers on the client side. I think this approach can be implemented without having an in-memory transport in between. You...

Re 2: that sounds like trace::Context? context::Context says "A request context that carries request-scoped information like deadlines and trace information." I think this wording applies to the use case we're...

Regarding the server-side request ID issue, I think there shouldn't be a need to change the request ID at all, though I realize now what I fleshed out earlier would...

Thanks for the PR! For now, I will continue the discussion on #392 and will wait to review this until I better understand the solution space.

Hi! Sorry for not responding last year. Did you still want help with this? Essentially, tarpc doesn't have any built-in transport, so everything is "custom" in a sense. You should...

Hi! Sorry, I missed this earlier. Thanks for filing. Generally, I would envision the client being identified by a load balancing layer, part of the transport (which tarpc doesn't bake...

Sorry for the delay in reviewing! Will try to look in the next week.