Most discussion is on Typelevel Discord: https://discord.gg/bSQBZA3Ced
It might be possible to have a model without log4s.
The headers are due for a massive reform anyway, so their current state is less interesting to that discussion.
It's interesting that all our integrations give the appearance of hard dependencies. The core is actually fairly light.
@SystemFw or others who might time to look. Put a PR up establishing an fs2 module for atto. Comments appreciated tpolecat/atto#91
@rossabaker would be excellent to see how we can move forward. I don’t see any reason why fs2-io backend couldn’t perform in pair with blaze-ds. If it does not, it means we still have work to do on perfromance, and this may be perhaps the focus of fs2-http to really make sure the core perfromance does not suffer
Then I love to have one single stack for Headers/Request/Response algebra, namely if you are in thoughts of revorking them.
I think pairboiled dependency is ok if we can prove its perfromance is far better than scodec one (btw could pairboiled be used with scalajs too?)
s.concurrently(SoS.join) is not onerous syntactically
it's just that it creates a queue and all that to collect values to
SoS that you then throw away
but that being said, I moved away from really caring about that
I do that occasionally to be sure. :laughing:
I guess the generalisation of this problem is what Pavel proposes
that mean you do nested
join without allocating all the queues
but it reduces the amount of things you need to allocate in the first place
I experimented with this in like M3, but it didn’t work, partly in bugs in cats effects I think. But now I am quite confident this shall work.
I'm just saying that you can't solve this:
def a = Stream(streamA1.drain, streamA2.drain).join
def b = Stream(streamB1.drain, streamB2.drain).join
def c = Stream(a.drain, b.drain).joinyou can reduce the initial cost of join, but you can't make the above be the same as
def c = Stream(streamA1.drain, streamA2.drain, streamB1.drain, streamB2.drain).joinunless you make join cost 0 (allocate no new primitives per join)
I do agree that a
joinDrain or something can be useful to reduce the cost of a single join in the first place, given the very common use case of just concurrently running things for their effect
unless we start doing magic things like introducing concurrency in the Stream algebra tree, with on-the-fly rewriting and stuff like that
but basically 1) modularity in the code, 2) modularity in the interpreter, or 3) extra allocation of machinery seem mutually exclusive
our current situation gives us 1) and 2) without 3) -- first code snippet
or 2) and 3) without 1) -- second code snippet
the interpreter needs to know about concurrency