You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
RequestReceived should contain priority information #234
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.
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.
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.
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.
Activity
Lukasa commentedon May 30, 2016
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 commentedon May 30, 2016
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
RequestReceivedis a good thing IMHO.Lukasa commentedon May 30, 2016
@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 commentedon May 30, 2016
Yes, copying the values to the
RequestReceivedis fine.Lukasa commentedon Jun 1, 2016
So then, the question becomes which of the following APIs we want to go with:
RequestReceivedthat contains duplicate information fromPriorityUpdated.RequestReceivedto aPriorityUpdatedevent if they were emitted simultaneously.frozensetobjects.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 commentedon Jun 1, 2016
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_idare 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 commentedon Jun 8, 2016
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 commentedon Jun 28, 2016
Resolved by #240.