Given that we're already defining the inner 'packet handler' types via an enum, I'm not sure the node trait buys us much. We had the following methods there:
name: return a string name for the node attach: attach a node after that one get_stats: get stats from the node visit: visitor
Anything that didn't already look a lot like the current node impl that had to implement all those methods...not sure the flexibility is buying us much there. We only had the one impl (DefaultNode) and the packethandler enum already seems to cover every use case (observing, filtering, transforming) so the flexibility can come from there.
It'd be great to have the pipeline "framework" not be packet/RTP specific and, instead, just be a generic set of logic for stringing together different nodes where each node can play different roles (observer, transformer, etc.).
Surprisingly, the enum seemed to play ok with the generic, i.e.:
pub trait Observer<T> {
fn observe(&mut self, data: T);
}
pub trait Transformer<T> {
fn transform(&mut self, data: T) -> Result<T>;
}
pub enum SomeHandler<T> {
Observer(Box<dyn Observer<T>>),
Transformer(Box<dyn Transformer<T>>),
...
} (i'd expected a trait object complaint there...maybe i just haven't gotten far enough along yet) But, the generics will be too viral, I think. If the handler is generic on T, then the Node, which holds a Handler, also has to be generic. That also means that NodeRef will have to be generic, and I think that feels like it'd be too much.