Graham Palmer

> We should probably reserve a range for a curated list of memory types, similar to what [IANA](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml) does That sounds reasonable. I'm probably not knowledgable enough to quickly come...

> Ideally with this we could introduce a builder like API which gives us the opportunity to return an iox::expected and leave it to the user to decide what happens...

Ah no, I think what you mean is that the builder pattern lets you return an error if the parameters aren't supported, right? It's a way of solving the classic...

Hi, Does a workaround / solution exist for this yet? > I think a workaround would be using ForwardRef or a NewType hook. Is there an example of how to...

I ended up coming up with this workaround: ``` @attrs.define class Foo: nested_dict: dict[str, Foo] = attrs.field(factory=dict) ``` ``` converter = cattrs.Converter() # Overriding the deserialization of this type is...

> If contention can lead to significant overhead I guess the framework should maybe provide support for mempool partitioning (by id or name) I have a PR for a design...

For partitioning mempools you can have a look at this PR chain: https://github.com/gpalmer-latai/iceoryx/pull/4 It is out of date with upstream and now there are merge conflicts with the experimental multiple...