Commit graph

10 commits

Author SHA1 Message Date
Parnell Springmeyer
112777023f
Plumb the MaxMetadataSize parameter through to the server (#134)
* Plumb the `maxMetadataSize` parameter through to the server

* Update `proto3-suite` dependency

* Bump proto3-wire to 1.2.2

* Re-generate Echo.hs

* Regenerate `Arithmetic.hs`

* Derp

* Fix codegen

* Update the tests for new codegen

* Patch-bump to `0.2.1`

* Bump to `0.3.0` to indicate a breaking API change...

Suggested by @intractable.
2022-02-25 16:23:22 -06:00
intractable
e1091b9c0d
grpc-haskell{-core} -> 0.2.0: Fix MetadataMap duplicate-key ordering (#132)
* Put LD_LIBRARY_PATH set back into Linux `nix-shell`

...as we need it for `ghci` workflows inside the shell(s).

* Add (failing) test case to check MetadataMap ordering

* Remove SortedList value-component from MetadataMap

...which fixes the failing test case introduced by `85a2d13`.

This is a potentially breaking change that warrants a library rev bump.

I'm not sure what the original reason was for the sorted list component of
`MetadataMap` (i.e., header values), but that implementation choice makes it so
that determining the "last provided" header value associated with a duplicate
key cannot be recovered. That is, it is in violation of this requirement from
the [spec](https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md):

```
Custom-Metadata header order is not guaranteed to be preserved except for values
with duplicate header names.
```

I'm guessing that the original motivation might have been to ensure that the Eq
instance was not sensitive to ordering of values for duplicate keys.

I think we can drop the existing `Eq` assumption about order-insensitive values
for duplicate keys (there is order sensitivity after all), and if we end up
discovering a common use case for an order-insensitive equality on values, we
should address that via a utility function (instead via the type's `Eq`
instance).

So, this commit changes the value component of the `MetadataMap` type to be a
list of `ByteString` values instead of `SortedList ByteString`, and removes the
`sorted-list` package as a dependency, as it has no other uses in the library.

Note that this commit is not claiming we are now spec-compliant w.r.t. header
treatment after this change. In particular (and at least),

1. We do not yet support base64-encoded binary data via the special `-bin` key
suffix.

2. As far as I am aware, we do not (yet) interpret comma-separated header values
the same as duplicate header keys for each of those values.

3. As far as I am aware, we do not (yet) do any validation of header names nor
whitespace handling as per the request grammar from the spec.

* Extend Arbitrary MetadataMap to explicitly encode key duplication

Duplicate keys were allowed by the previous implementation, but this commit
makes key duplication more explicit and more frequent.

* Add metadata map ordering QC prop

* Drop qualified use of @?= since it's so common in this module

* Extend checkMetadataOrdering to check instance Eq MetadataMap

...and use the appropriate bracketing wrapper.

* Relocate MetadataMap type to its own module

* Add some helper functions for MetadataMap lookup; documentation

* Extend testMetadataOrdering w/ use of lookup{All,Last}

* Bump grpc-haskell{,-core} -> 0.2.0
2021-06-30 20:32:33 -05:00
intractable
b9ed537f64
Minor cleanup (#130)
* Remove unnecessary self-dependency

* Regenerate core/default.nix and build -core via callCabal2nix

* grpc-haskell-core: -Wall -Werror and fix warnings

* grpc-haskell: -Wall -Werror and fix warnings

* Update documentation

* Remove LD_LIBRARY_PATH sets from usesGRPC

...as they no longer seem to be needed.

* Remove dead code

* Remove core/default.nix

...as suggested by @evanrelf.
2021-06-30 12:31:45 -05:00
Gabriel Gonzalez
8525994a4f
grpc-haskell-core: Version 0.0.0.0 → 0.1.0 (#126) 2021-05-14 14:34:57 -07:00
Moritz Kiefer
11681ec6b9
Fix sdist tarballs (#88)
A bunch of files have been missing from the tarballs created by `cabal
sdist`. I’ve changed the nix config to check for this and also found
some examples that I forgot to update in a previous PR (sorry about
that).
2019-08-28 09:28:26 +02:00
Moritz Kiefer
5ceeae74cc Upgrade to gRPC 1.22 (#85) 2019-08-22 11:12:21 -05:00
j6carey
75cf21839b
Port grpc-haskell[-core] to ghc-8.6 and modern tasty. (#77)
Note that even though we can now build grpc-haskell and grpc-haskell-core
with modern tasty, the environment in which we built those test programs
did not support actually running all them successfully, due to the need to test
generated code in the context of the appropriate libraries.  We do not yet
know whether test programs built with new versions of tasty would succeed
in the appropriate environment.  In principle this could be discovered, but
the work involved is far from trivial, and therefore we defer it to another
time.  Tests built with the old tasty still succeed.
2019-03-25 16:52:04 -07:00
Ewout
9c6b3f63b6 Fix build on GHC 8.4 (#63)
* Fix haddock: postfix comments on GADT constructors don't work.

See https://github.com/haskell/haddock/issues/43 .

* Remove unused dependencies from cabal file..

* Semigroup instances for compatibility with GHC 8.4.
2018-06-18 12:24:19 -07:00
Christian Lavoie
5fd44880da Remove proto3-wire dependency from core package. (#47) 2018-01-30 09:20:05 -08:00
Christian Lavoie
9cfb3da770 Extract lowlevel bits into a core package (#42) 2018-01-29 08:59:34 -08:00