Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 07 22:58
    rossabaker opened #298
  • Dec 07 21:38

    github-actions[bot] on gh-pages

    deploy: c8edae20c6ac46af0dd1a56… (compare)

  • Dec 07 21:32

    armanbilge on series

    (compare)

  • Dec 07 21:32

    armanbilge on 0.23

    Update vault to 3.4.0 in series… Merge pull request #6854 from h… (compare)

  • Dec 07 21:32
    armanbilge closed #6854
  • Dec 07 20:27
    mergify[bot] labeled #6854
  • Dec 07 20:27
    mergify[bot] labeled #6854
  • Dec 07 20:27

    http4s-steward[bot] on series

    Update vault to 3.4.0 in series… (compare)

  • Dec 07 20:27
    http4s-steward[bot] opened #6854
  • Dec 07 19:26
    armanbilge commented #6832
  • Dec 06 17:32
    armanbilge closed #6851
  • Dec 06 17:24

    github-actions[bot] on gh-pages

    deploy: 2c034f6e72ff5524e124fbb… (compare)

  • Dec 06 17:13
    danicheg closed #6853
  • Dec 06 17:13

    danicheg on 0.23

    Add default case and test Merge pull request #6853 from m… (compare)

  • Dec 06 17:06
    armanbilge commented #6852
  • Dec 06 17:05

    github-actions[bot] on gh-pages

    deploy: c2166c6b132b6d98eb26ef6… (compare)

  • Dec 06 17:05
    armanbilge commented #6852
  • Dec 06 16:59

    armanbilge on 0.23

    Add fs2-data to integrations do… Merge pull request #6850 from y… (compare)

  • Dec 06 16:59
    armanbilge closed #6850
  • Dec 06 14:17
    mattyjbrown commented #6853
Niklas Klein
@Taig
@Daenyth That's an interesting catch. I wasn't aware that might be blocking the queue. I'm basically just parsing json, but I might wanna step into the flamegrapghs to find out more.
Gavin Bisesi
@Daenyth
oof that reminds me, I need to get us up from 0.20.0-M5
@Taig json parsing is heavily cpu bound IME
Christopher Davenport
@ChristopherDavenport
I’ve been on vacation, my notification list is 29 http4s issues, with many of them PR’s what is most pressing?
Gavin Bisesi
@Daenyth
I'd definitely do something like fs2.Stream.emits(requests).mapAsyncUnordered(cpuCount)(req => send(req).flatMap(handleResp)) or something
Ross A. Baker
@rossabaker
I just milestoned the 0.20.2 ones
Christopher Davenport
@ChristopherDavenport
Where doews #2604 invoke getDefault? Are we worried this will bite us?
i.e. behavior will change with default behavior having an SSL context or having no ssl context.
As if we were deferring creation, I’d expect I’d see where we called that later with the delayed call.
Ross A. Baker
@rossabaker
I don't really like it. If you're on a system where getDefault throws, it just defers the explosion until the first https call. But the reason it's there is that it gives people who know that getDefault throws a chance to override it. The crucial point is that getDefault not appear as a default argument. That's why we've gotten that bug filed ... twice.
Christopher Davenport
@ChristopherDavenport
Alright. Lets go with it, but lets make it big in the release notes.
We
*We’ll still get the issue
Ross A. Baker
@rossabaker
I would like to do better there, but it's the best I could figure out to do without breaking bincompat.
Christopher Davenport
@ChristopherDavenport
I believe that unblocks 0.20.2
Ross A. Baker
@rossabaker
There's absolutely no way to create an SSLContext that's guaranteed to work, which suggests maybe it should be an Option.
Christopher Davenport
@ChristopherDavenport
Yeah, I think it will still blow up though.
So…
Ross A. Baker
@rossabaker
If it were optional, it would fail with a message of our choosing if someone attempts to make an https call and doesn't have it configured.
And it still needs to be lazy, because Some(sslContext.getDefault) is the right choice for most people.
Christopher Davenport
@ChristopherDavenport
lazy should not be our tool to defer.
but, thats for a binary-breaking change.
Ross A. Baker
@rossabaker
Right. I started speculating on either the original or on the PR what we could do when we do break binary.
Christopher Davenport
@ChristopherDavenport
Http1Support should just take SSLContext
Then we need to explicitly deal with it somewhere after server creation.
Ross A. Baker
@rossabaker
Later is another way of making it lazy to defer.
SyncIO makes it lazy and expresses Dragons Be Here.
F[SSLContext] could have a reasonable default.
I don't like the last two because I tend not to like passing effects as parameters.
Christopher Davenport
@ChristopherDavenport
Except we can’t access that.
Our implicits being in last position is really a PITA
I really want (implicit XYZ)(argumentList)
Ross A. Baker
@rossabaker
Yeah.
If we passed Http1Support and F[SslContext], we've got a ConcurrentEffect[F] (which I'm not proud of), and then could run it in the constructor.
Keeping it lazy in Http1Support is still important though.
We couldn't just strictly run that effect in Http1Support, or we'd break people who can't get an SSLContext and don't want one.
Christopher Davenport
@ChristopherDavenport
Really, how do you opt out?
As that seems like a value that could be evaluated and not properly seperated if we are concerned about that.
Ross A. Baker
@rossabaker
After the bug fix, you opt out today by not making https calls or by creating one that works.
Christopher Davenport
@ChristopherDavenport
Right, seems like we really could split that, rather than having a val that could blow up at any moment in a server that doesn’t intend to support http4s
Not really relevant to this iteration, but long term. Why have both in the same thing rather than a coproduct.
Ross A. Baker
@rossabaker
I'm hazy on what we're splitting.
Christopher Davenport
@ChristopherDavenport
SSL capable servers.
Or clients.
Fabio Labella
@SystemFw

I really want (implicit XYZ)(argumentList)

What's the implicit there? (quickly scrolling)

Ross A. Baker
@rossabaker
Oh... well... hmm.
Christopher Davenport
@ChristopherDavenport
But basically the lazy val is what protects us from blowing up.
Ross A. Baker
@rossabaker
We don't have secure and unsecure requests at the type level.
Christopher Davenport
@ChristopherDavenport
@SystemFw (implicit F: Sync[F])(foo : F[XYZ] = F.delay(xyz))