Much harder with V2 than V1 to send binary CloudEvents

[eamonnmcmanus]

I might be missing something, but it seems to me that it has become much harder to send binary CloudEvents with the V2 SDK, unless you happen to be using one of the small number of supported HTTP clients. In V1, I could write this:

Wire<String, String, String> wire = Marshallers.<Map<String, Object>>binary()
        .withEvent(() -> myCloudEvent)
        .marshal();

Then I basically just needed to copy wire.getHeaders() into the HTTP headers of the request and have wire.getPayload().get() be the HTTP body. That's easy to do with pretty much any HTTP API.

With V2 it looks like I am out of luck if there isn't already a MessageWriter defined for the specific HTTP API that I am using. It's not that hard to make a MessageWriter by following the example of one of the existing ones, but it's still about 50 lines of non-trivial code.

Could we have the simplicity of V1 back? Perhaps with a trivial MessageWriter implementation that just stashes the HTTP headers in a Map<String, String> and the body in a byte[] or whatever, which is more or less what the old Wire did. It's nice that the supported HTTP clients are so easy to use, but it seems to be at the cost of making anything else much harder.

[olegz]

This is yet another argument for why we should not be pursuing #198, #208 and #211 where we attempt to assume things we don't really know anything about. This is all about separation of concerns. CloudEvent represents an instance of itself, but it has to be transmitted over many mediums. . . some may be well known and some may be fully custom, so yes, having a canonical-ready-to-ship representation of CloudEvent containing ready-to-go parts only requiring mapping to specific transmission structure (as described by @eamonnmcmanus) is definitely the right path forward.

[slinkydeveloper]

Could we have the simplicity of V1 back? Perhaps with a trivial MessageWriter implementation that just stashes the HTTP headers in a Map<String, String> and the body in a byte[] or whatever, which is more or less what the old Wire did. It's nice that the supported HTTP clients are so easy to use, but it seems to be at the cost of making anything else much harder.

I think this is trivial to implement, we can definitely have one in cloudevents-core. Although, that won't be optimized for the specific http libraries, eventually creating huge performance penalties b/c of memory copy (in particular, of the headers...).
Do you want to contribute it @eamonnmcmanus?

[bsideup]

b/c of memory copy (in particular, of the headers...)

FTR since headers are represented by Strings in most frameworks, unless measured, I would not say that there are "huge performance penalties" due to them. @slinkydeveloper have you done some research on this? Maybe some benchmarks to share?

[slinkydeveloper]

I didn't any particular research on the matter. The allocation you may incur are:

• The Map<String, String> itself
• The String header names: some frameworks/libraries may reallocate the header name string, depending on the internal representation (for example, vert.x does it and that's why we preallocate those strings).

Anyway, I think we can give it a shot, develop a benchmark and check the results. If we're happy with that, I'm definitely +1 to ship it.

[bsideup]

The Map<String, String> itself

There is no need to allocate a Map, as long as the names can be enumerated

The String header names

One can easily "cache" the names (e.g. by using constants) and/or some sort of a cache. Given that the set is final and small, it should be fine.

[slinkydeveloper]

There is no need to allocate a Map

As soon as you have extensions, you need to allocate it... Anyway, let's try to implement it and let's check the result 😄

[matejvasek]

@eamonnmcmanus I tried to create generic http binding #225, please look at it.

[matejvasek]

It the PR #225 I added generic Message(Reader|Writer) and factory methods to instantiate them + some convenience static methods:

public static CloudEvent readCloudEvent(Map<String,String> headers, byte[] body) ;
public static void writeCloudEventBinary(CloudEvent cloudEvent, BiConsumer<String, String> putHeader, Consumer<byte[]> putBody);
public static void writeCloudEventStructured(CloudEvent cloudEvent, EventFormat eventFormat, BiConsumer<String, String> putHeader, Consumer<byte[]> putBody);
public static void writeCloudEventStructured(CloudEvent cloudEvent, String eventFormat, BiConsumer<String, String> putHeader, Consumer<byte[]> putBody);