Let users specify their own message priority type instead of u32 (#85)

[Restioson]

No description provided.

[thomaseizinger]

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?

[Restioson]

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?

[thomaseizinger]

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

[thomaseizinger]

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.

[Restioson]

That's true. I mostly worry about the flexibility concerns here.

[thomaseizinger]

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.