RequestReceived should contain priority information

[Kriechi]

A follow-up on #229 and #233:

It would be nice if the RequestReceived event contains priority information, if the HEADERS frame carries them. This way all available information about a new request is in the same event. PriorityUpdated is then only used for actual PRIORITY frames.

[Lukasa]

So I'm not sure exactly how we want to do this yet.

We could put the priority information in RequestReceived, but that means that priority information isn't obtained isomorphically regardless of the source: instead it needs to be found in different places depending on how the information was sent. I don't think I love that much.

I think I'd rather we decided on a solution for #228 that allows understanding this information without forcing people to know about it if they just want to handle the priority information wherever it came from.

[Kriechi]

Maybe I misunderstood you, but you sounded more enthusiastic about it in #233 (comment).

#228 sounds more like a 3.0 kinda thing. As a backward-compatible solution, putting priority information into RequestReceived is a good thing IMHO.

[Lukasa]

@Kriechi We can duplicate the priority information in there, but we can't move it there, because that would also be a breaking API change.

[Kriechi]

Yes, copying the values to the RequestReceived is fine.

[Lukasa]

So then, the question becomes which of the following APIs we want to go with:

1. Add new data to RequestReceived that contains duplicate information from PriorityUpdated.
2. Add a link from RequestReceived to a PriorityUpdated event if they were emitted simultaneously.
3. Add support for emitting events as frozenset objects.

Doing 3 is a major version bump which we're considering anyway, so let's restrict ourselves to 1) and 2). Do you have a preference here?

[Kriechi]

1. is probably the simplest and requires only minimal changes / additions to the API.
2. sounds like a nice idea - not sure how efficient this can be done. Ideally all events with the same stream_id are linked to each other.

Unless you really dislike duplicating the values between two events, I would prefer 1.
But I'm also happy with 2.

[Lukasa]

Ok, I'm prototyping a solution based on (2), because it has the handy property of being a good stepping stone to potentially implementing @rbtcollins' "frozenset" based idea for #228: that is, it'll get people used to the idea that they may want to check a set for other things before processing too far.

[Lukasa]

Resolved by #240.