These changes were generated automatically by running "Analyze and Code Cleanup".
Showing a diff ignoring whitespace shows the removal of the UTF-8 BOM from three files, but that's all.
Signed-off-by: Jon Skeet <jonskeet@google.com>
- New methods in CloudEventFormatter to support inference
- JsonEventFormatter infers a content type of application/json for non-binary data
- All transports use the inferred content type when formatting in binary mode
- Documentation for both formatters and bindings has been updated
Signed-off-by: Jon Skeet <jonskeet@google.com>
This sometimes feels a little cumbersome, with conversions that will
*sometimes* involve copying data, but leaves room for optimization
later and is a more flexible API in the long term.
Signed-off-by: Jon Skeet <jonskeet@google.com>
There's discussion about exactly what CloudEvent web hooks should
look like: https://github.com/cloudevents/spec/issues/781
We can remove the code until that's resolved.
Fixes#154
Signed-off-by: Jon Skeet <jonskeet@google.com>
This is enough to validate that #49 is fixed.
(More thorough HTTP tests would be very welcome, of course...)
Signed-off-by: Jon Skeet <jonskeet@google.com>
If this pattern looks okay, the next steps are:
- Implement for all other HTTP bindings
- Adjust the IsCloudEvent for all bindings (to ignore batch)
- Implement for any other bindings that support batch
Signed-off-by: Jon Skeet <jonskeet@google.com>
I'm still not entirely convinced by the approach here, to be honest... but at least the error handling is now centralized.
Signed-off-by: Jon Skeet <jonskeet@google.com>
This is largely a matter of clarifying responsibilities and adding
documentation to CloudEventFormatter and our current
implementations. Additionally, the content type of the message is
now passed to structured-mode decoding methods to assist with
aspects such as character encodings.
The methods have been renamed to make it clearer that it's the
message that uses structured or binary mode, not the event itself.
(There's no such thing as a "structured mode CloudEvent" or a
"binary mode CloudEvent".)
Signed-off-by: Jon Skeet <jonskeet@google.com>
This allows us to remove the Newtonsoft.Json dependency from the
SDK, and implement another event formatter based on System.Text.Json
later on. That should probably wait until we've iterated on the
design of event formatters though.
This commit moves us closer towards (but doesn't fix) #42.
Signed-off-by: Jon Skeet <jonskeet@google.com>
This touches almost file in the repository, because it's hard not to
with such a fundamental change.
There are *lots* of TODOs now, all of which we should chase down
before release. In most cases this isn't a new problem - it's just
one that wasn't noted before,
The two main changes are:
- Spec versions, attributes, and attributes types are now first-class
types. Rather than being able to set attributes to any value you
want, values have to be of the right type and have a valid value
(e.g. for datacontenttype). This centralizes value conversion
for the most part (although transport/format-specific conversions
may still be required) and makes everything more predictable.
- Extensions are now *not* first-class types; instead, the extension
attributes can be registered with the CloudEvent in order to perform
appropriate validation etc, and a pattern around extensions
providing extension methods on CloudEvent allows them to be used
easily.
This work has revealed a lot of smaller problems, such as the HTTP
transports propagating a content of "null" (rather than no content)
when no data was set in the CloudEvent. More testing is certainly
required.
It's worth noting that this is a really big breaking change. The 2.0
release was already going to be breaking, but this is much larger
than the previous changes. I assert that the benefits outweight the
costs though, and even though the package already has many users,
we hope there will be many times more users in the future.
Proposed process for this PR:
- This initial commit does not include nearly as many unit tests for
CloudEvent, CloudEventAttribute or CloudEventAttributeType as I'd
like. Those will come in a follow-up commit (which should be
reviewed before merging) but don't affect the review of the overall
ideas.
- If the general thrust of this PR is acceptable, then I propose we
merge it, only making changes to the most egregious problems, and
leaving further clean-up work (of which there's likely to be a lot)
to later PRs. It's easier to create a clean-up PR in Visual Studio
than to suggest fixes via GitHub.
Style changes:
- Use explicit access modifiers
- Move using directives before the namespace declaration
- Unit tests are generally more separated out to correspond to
production classes, and are in separate directories/namespaces
by project instead of all at the top level.
Currently StyleCop is not installed, but we should probably either
do that or use regular Roslyn analyzers in the long term - along
with turning on XML documentation generation.
Signed-off-by: Jon Skeet <jonskeet@google.com>
Jon Skeet