Mateusz Front
Mateusz Front
## Sending 'pause' messages instead of demands Instead of sending demands, a consuming element could send 'pause' messages upstream to notify the preceding element not to send further packets till...
Automating demands: #285 Linking multiple elements within one process: #293
The behaviour could also be selected when removing a child
Yup, `orphan_child` was what I thought of
As @bblaszkow06 pointed out, this can be solved by doing ```elixir assert_sink_buffer(pipeline, :sink, buffer) assert %Buffer{...} = buffer ``` and waiting can be avoided by ```elixir assert_end_of_stream(pipeline, :sink) refute_sink_buffer(pipeline, :sink,...
Maybe events of the same type could override one another
We could have a function calculating the key from the event (defaulting to event type). Then we could override events that have the same key
Some of these things are already documented, but as comments in the code, e.g. element's internal architecture is briefly described [here](https://github.com/membraneframework/membrane-core/blob/master/lib/membrane/core/element.ex).
`Membrane.Core.Parent.MessageDispatcher` is still to be refactored out
Partially done by #203