Let users specify their own message priority type instead of u32 (#85)
Restioson opened this issue · 6 comments
Why is u32 not good enough? Are you thinking of custom priorities with enums?
A potential downside of more type parameters might be increased compile-times, plus such a type may have to be carried through extension libraries of xtra, depending on how they extend things.
u32 might even be a bit much for priority, perhaps u8 is enough?
Why is u32 not good enough? Are you thinking of custom priorities with enums?
Yes, this is what I was thinking. It might be a bit easier to reason about
u32 might even be a bit much for priority, perhaps u8 is enough?
That's true, but maybe it's better for now to err on the side of more rather than less?
Why is u32 not good enough? Are you thinking of custom priorities with enums?
Yes, this is what I was thinking. It might be a bit easier to reason about
We could go the same route as logging levels here and simply provide a fixed set of priorities:
- Minimal
- Low
- Default
- High
- Asap
An advantage of a fixed set of priorities would be that we can guarantee FIFO across a single priority because we can implement it by just having one queue per priority instead of a heap and therefore not mix messages of different priorities into one data structure.
What do you think of that? I quite like the simplicity of having only "low", "default" and "high" priority messages.
That's true. I mostly worry about the flexibility concerns here.
That's true. I mostly worry about the flexibility concerns here.
Yeah I can see that. Given how much it could simplify internally, what do you think of trimming the feature down initially and see if someone complains about the lack of more priorities?
Even if we start with low, default and high, we can always add 1-2 more before having to switch conceptually.