Try to work out a way of only avoiding duplication

[jskeet]

With our current approach, we have duplication between serialization packages - both Google.Events.Protobuf and Google.Events.SystemTextJson include a "StorageEventData" type. This is to avoid forcing users to have a dependency on any particular serialization framework - both to avoid conflicts, and to allow functions etc to have minimal dependencies. The downside is that it adds a choice (which package to use) and could make it hard for libraries to be written that would like to be serialization-framework-agnostic.

Ideal requirements (noting that the Functions Framework can change - we don't have to worry about compatibility with the current alpha):

• Not too closely tied to Google - it should be easy to consume CloudEvents that aren't from Google. (This may mean we need a "converter registration" mechanism in addition to "find the annotation on the data type")
• Avoid dependencies as far as possible
• Portability across serializers: ideally there'd be a single "serializer-agnostic" representation of each event type, and then conversion uses whichever serializer the user has plugged in

One potentially-inefficient option: if we had a serializer-agnostic representation in Google.Events, but then serialized "via" an internal class per serializer, that could work. The conversion between serializer-specific type and agnostic type could get hairy, and there are interesting versioning concerns... but it's a possibility.

[jskeet]

Closing this, as we haven't had any feedback that using protobuf is a problem.

There's no direct dependency from the Functions Framework onto any code in this repo now - the CloudEvents SDK has an attribute which allows an appropriate event formatter to be used, so that's not an issue. If we wanted a System.Text.Json version of the events, there'd still be duplication though.