Baseline Transition for Vault Use #2318
Conversation
| if (parser.getHttpVersion().minor == 1 && parser.isChunked()) { | ||
| val trailers = new AtomicReference(Headers.empty) | ||
|
|
||
| val attrs = AttributeMap.empty.put[F[Headers]]( | ||
| val attrs = Vault.empty.insert[F[Headers]]( |
There was a problem hiding this comment.
Here we insert a value as an arbitrary F defined by the server, but could be read as a different effect type elsewhere. This is a bit worrisome.
There was a problem hiding this comment.
Instead of exposing Message.Keys.TrailerHeaders[F], can we hide it away as a method on Message so that getting and setting can only be in the Request's F?
|
|
||
| package object websocket { | ||
| private[this] object Keys { | ||
| val WebSocket: AttributeKey[Any] = AttributeKey[Any] | ||
| val WebSocket: Key[Any] = Key.newKey[IO, Any].unsafeRunSync |
There was a problem hiding this comment.
This is where we can get in trouble with effect type mismatches.
|
|
||
| private[this] object Keys { | ||
| val PushResponses: AttributeKey[Any] = AttributeKey[Any] | ||
| val PushResponses: Key[Any] = Key.newKey[IO, Any].unsafeRunSync |
There was a problem hiding this comment.
Another problematic spot.
|
I'm just ecstatic that its such a small diff and it compiled and tested clean. |
There was a problem hiding this comment.
So, there's the issue with the trailer headers, which seems independent of Vault vs. AttributeMap. That needs to be cleaned up no matter how we proceed.
A second comment is about Vault itself: much of this diff is changes of method names from those inspired by scala.Map to those that match Data.Vault.Lazy. Data.Vault.Lazy itself uses function names that look like Data.Map. I wonder whether the Scala port would be better using scala.Map names for operations instead of a literal Haskell translation. Make it an idiomatic port rather than a literal port. It would certainly shrink this diff.
Finally, to this PR itself: the keys are always unsafeRunSync()ed in the Vault implementation, and we just changed the names of all the methods. I like Vault, and probably would have happily copied that instead of AttributeMap had it existed during The Bootstrapping. But what do we gain from switching now? The only thing I can think is referential transparency when custom keys are handled in an effect, but we uncovered no internal use cases of that. Is Vault safer or better in any other way?
| if (parser.getHttpVersion().minor == 1 && parser.isChunked()) { | ||
| val trailers = new AtomicReference(Headers.empty) | ||
|
|
||
| val attrs = AttributeMap.empty.put[F[Headers]]( | ||
| val attrs = Vault.empty.insert[F[Headers]]( |
There was a problem hiding this comment.
Instead of exposing Message.Keys.TrailerHeaders[F], can we hide it away as a method on Message so that getting and setting can only be in the Request's F?
| @@ -29,6 +29,7 @@ lazy val core = libraryProject("core") | |||
| fs2Io, | |||
| log4s, | |||
| parboiled, | |||
| vault, | |||
There was a problem hiding this comment.
Inlining this dependency is still the big elephant in the room.
|
|
||
| val Destination = AttributeKey[String] | ||
| val Destination = Key.newKey[IO, String].unsafeRunSync |
There was a problem hiding this comment.
Can we make this private if we're doing the unsafe thing?
|
I think i give Vault an edge over AttributeMap because, even if we do |
|
I don't see a need for vault to change, but could make java/scala style methods as well which could reduce additional noise. I don't mind doing the work here after the other PR's are all in with changes to attribute maps. As far as the fact that it currently only does it this way, that was intentional. I wanted to sign the waiver to start off with, but later we could make middlewares return tuples with the key to extract the values generated by that middleware etc, which I believe would often be a better pattern. However I thought that the minimal piece was ideal. As per the library dependency. Utilizing a shared tool means that this can and will translate with other peoples vault use. Where as an internal one means that conversions would be required to work with the library. I think it has value, but do understand the reticence. |
This is a baseline transition for Vault use.
attributes?