Make it easier to create your own transport implementation

[thomaseizinger]

Problem Statement

I am currently writing my own transport implementation and would like to reuse the tokio-thread and rate limiter modules from sentry.

Solution Brainstorm

Solution 1: Publicly expose these modules

Pro: Very easy to do Con: Sem-ver liability because it increases API surface

Solution 2: Create a dedicated sentry-transport crate

Pro: Can be versioned independently of the main crate, no additional API surface for sentry Con: Requires a bit more work

[linear[bot]]

RUST-129

[lcian]

Thanks for the suggestion, we'll evaluate how this could be improved.
Could you share why you need to implement your own transport? Is there anything that's not working with the built-in ones?

[thomaseizinger]

Could you share why you need to implement your own transport? Is there anything that's not working with the built-in ones?

We are using Sentry in @firezone and in order to not create routing loops, I need to control the creation of the underlying socket. We have our own abstraction for that and I built an HTTP2 client on top of it.

Thanks for the suggestion, we'll evaluate how this could be improved.

If I had to maintain this workspace, I'd create a dedicated crate which is used by the Sentry transports but not exposer publicly to make sure it is not a semver liability.

[szokeasaurusrex]

Hi @thomaseizinger, I think we will go with publicly exposing the modules. I have added this issue to our internal backlog — if you would like it to be available sooner, you are welcome to submit a PR.

[thomaseizinger]

Okay cool, thanks for the quick decision. I'll put up a PR in a bit. I also have a small change request but we can discuss that separately.

[thomaseizinger]

I opened two PRs for this: #949 & #950