Bastian Bloessl

I guess, there is no right or wrong optimization. Just one that works better or worse. I don't know what is better and also Ettus is not clear on that:...

We already have functional-style blocks (`map` -> `Apply`, `filter` -> `Filter`, etc). See the top [here](https://docs.rs/futuresdr/latest/futuresdr/blocks/index.html). But, at the same time, an SDR is not an Iterator and it is...

At the moment, this would be something like: ```rust let block = FileSource::::new("my_filename.cf32", false); let map = Apply::new(|s: &Complex32| s * 0.5); let filter = Filter::new(|s: &Complex32| if s.abs() <...

I think that, at the moment, we could get the `Terminate` message either from an external source through the flowgraph handle or when a block encounters an error, e.g., during...

Yes, this is exactly what I meant. `BlockError` and `Terminate` seem like good terms to me. Regarding the termination logic in case of a block error, we could consider this...

I'd say that FutureSDR is a SDR runtime. And every runtime I know of distinguishes these two primitives. It's just natural for the problem. These two port/connection types also implement...

Great, looking forward to your prototypes!

Thanks for the PR! I think, it would be nice to allow serialization of `dyn Any` types. However, as we already discussed, I think we probably shouldn't force it on...

(Btw, you don't have to merge back `main`. If you want to keep the PR up-to-date, a rebase would be preferred, since I think it's nicer to not have merge...

Thanks for the change. With this, it could be merged without forcing it on everybody. The wrapper struct, for example, is easy, but it's not obvious for the user, why...