Should requests be mutable or immutable?

[aantron]

Request bodies are already mutable, because of the use of one-time callbacks/promises (rather than buffering streams). There are hidden mutable fields in requests for internal purposes, and there might be future hidden mutable caches.

Making requests fully mutable would simplify some of Dream's code, and save on allocations during immutable updates (but this can be mitigated in some other ways, as well).

I'm having a hard time seeing the use case for immutable requests — i.e. I don't think a Web app really ever needs to share them along different "execution paths."

Dream hasn't committed either way yet. It just provides an immutable-looking request API with a partially-mutable implementation.

[shawn-mcginty]

For what it's worth, mutable requests sounds like the most sane option to me. I'm not certain but I would guess that it would improve performance and as you said above the API could look/feel immutable for dev happiness and to conform with idiomatic OCaml.

Maybe some testing could be done to see impact on performance?

[aantron]

Maybe some testing could be done to see impact on performance?

I'll probably write some benchmark that passes requests through a biggish stack of middlewares that tweak them, and compare mutable vs. immutable semantics.

Mutable also sounds more sane to me, but it just doesn't "feel" functional :) However, this is OCaml :)

I'll probably ask on the forum at some point, while Dream is still in alpha releases, too.

[aantron]

d7e81a2 makes requests and responses (messages) mutable. I decided not to profile it — after factoring out the core more carefully in preparation for the Dream client library, the server code written over the core practically required mutable messages in order to be sensible (to avoid returning requests and responses and rebinding them everywhere as the code gets split up into core and server modules).

The code does seem less silly without constant rebinding of messages everywhere. Messages were already mutable internally, because they had ephemeral streams, mutable multipart upload state, and I always planned the possibility of mutable caches for things like cookie parsing results. The above commit just "commits" to mutable messages fully, and takes advantage of some simplifications that are possible that way.