Less code does not necessarily equate to less bugs, especially since you’re replacing well understood code with code that has not had nearly the same amount of attention.
Just to be clear, I’m not opposed to the idea of a shuffler based server. Were you introducing something new, I would have little reason to object, but this is code that has been in place for 10-15 years (or more) and as such should be subject to appropriate caution, testing and scrutiny before it replaces the default implementation.
In short, subclass Request, implement shuffler there and add it as an option alongside the standard request object. There’s plenty of precedent for that (various backend flavors, various hilfes, etc) and that approach won’t cause any heartburn for anyone.
Bill
Sent from my iPhone
On Jun 14, 2019, at 9:14 AM, Stephen R. van den Berg srb@cuci.nl wrote:
Tobias S. Josefowitz @ Pike developers forum wrote:
It's not that the Request class is supercomplicated. The code is relatively straightforward, so it should be easy to fix if anything comes up.
And only months to years later distributions would supply any user with the fix in a new version of Pike!
While I have not yet had time to look at your changes, on a very general level I agree with Bill, "we can fix it later" is not a good argument; with something as prominent as Protocols.HTTP we should certainly develop the confidence that a change is not going to have negative impact in the field before considering to include it in a release.
Ok, point taken. Then again, if anything, the proposed changes to Server.Request simplify the code *a lot*, which (IMO) does count towards making it easier to guarantee correctness (quite possibly even fixing any lingering bugs in the old code). -- Stephen.