Planning: Breaking changes for trillium 0.3

[Jacob Rothstein]

Breaking Changes

Note

This is non-exhaustive and none of these are certain, so please provide feedback and suggest further breaking changes

Checkboxes indicate merge to the 0.3.x staging branch

trillium

• remove impl Handler for Arc<Handler> -- the primary use case for this is internal to trillium, and should be implemented for a newtype wrapper, as we can ensure that we call init prior to cloning. There is no implementation of init that will avoid a sharp edge for someone

• #610

• #609

• #608

• pare Info down, lean on StateSet (#398)

• consider making Handler not object-safe by returning impl Future instead of using async_trait and instead introducing a BoxedHandler; this would be worth only worth it if it represents a performance improvement.

• use Swansong instead of Stopper + CloneCounter + CloneCounterObserver

• Introduce IntoHandler and require all Handler implementations to #[derive(IntoHandler)] or impl IntoHandler for Whatever { type Handler = Self; fn into_handler(self) -> Self { self } }

• figure out if there's a way to avoid trillium reexports trillium-http types from locking server-minor versions; ideally trillium-http could make breaking changes that only require a trillium patch change as long as the reexported types aren't breaking

trillium-http

• make all fields on Upgrade private and add accessor functions
• replace all reexported error types with intrinsic variants that don't contain external implementation details (and allow breaking changes in the contained types)
• Synthetic::len should return usize (if Synthetic isn't removed entirely)
• use Swansong instead of Stopper
• treat non-utf8 header value content as opaque data (using String::from_utf8_lossy) instead of trying to retain the full content. Trillium goes above and beyond what the spec says is necessary
• remove httparse deferred for 0.3.1 since this has no external api changes.
• #657

[Josh Triplett]

• consider making Handler not object-safe by returning impl Future instead of using async_trait and instead introducing a BoxedHandler; this would be worth only worth it if it represents a performance improvement.

It would also be worth it if it's performance-neutral, since it would substantially improve the quality of the documentation, and eliminate the need to append (and maintain) "here's the actual async fn signature".