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]

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.