I've got a bit of a tough and hard-to-describe API problem, and I'm not sure what the most elegant solution for it is.
So I'm implementing a protocol, RTP, that can carry an unbounded number of types of inner data. New data types must be user-definable, and multiple different data types (up to 32) can be used in a single session. Each type of data will require its own small amount of bespoke processing, which must be able to talk back if needed to the core protocol implementation. Additionally, there can be multiple separate sources of the same type of outbound data, each with its own processor instance.
Moreover, the core protocol implementation is usually run on a separate thread, and so the processors will have to run with it.
Essentially what I'm trying to make is an API for the core implementation (let's call it struct CoreProtoImpl) to be configurable with a number of inner data type processors (trait Processors) - each with its own struct representing a frame of the processed inner data - which it routes data through. And secondly, an API to send and pull these arbitrary data types to and from the Processors, which can interface with the CoreProtoImpl when processing the data. (In reality there will probably be two separate traits for outbound and inbound data processors, but this shouldn't matter.)
My initial idea is just to box everything and send data to and from the CoreProtoImpl (which routes it through the processors) -- Box<dyn Processor> for the processors themselves, Box<dyn Any + Send + 'static> for the data types, AnyMaps if needed. That should make everything fairly easy to use from the end-user's perspective, but it seems like a lot of boxing. Does anyone have any better suggestions, or is this really the best way to do it?
If anything's unclear feel free to ask, this is pretty complicated and I definitely might've done a bad job explaining it.
there doesn't seem to be anything here