Events should contain information about source channel

[nicolaferraro]

As discussed shortly in the Slack channel, in order to implement conditional logic at application level, events forwarded by a channel should contain information about the channel itself, so a application framework can dispatch them to the right handler.

This is useful in services that need to subscribe to multiple channels and treat events differently based on their origin.

A possible way to implement this is to use Cloudevents extensions that have a http binding mapping them to CE-X-Yyy headers.

We can use CE-X-KnativeChannel to set the source channel. I don't think there's need to track the history here, but only last one.

I can work on this.

[evankanderson]

Would adding a URL path or other distinguishing routing information work for this purpose?

I'm slightly concerned about this pattern as it seems to violate a few of our design principles:

enable late-binding event sources and event consumers

If the consumer needs to know about the channels connected to it, it seems like this pushes the binding early (into the design phase), and makes the overall design more brittle.

Services can be connected to create new applications without modifying producer or consumer

This is a restatement of the above -- in this case, it feels like the consumer would need to be modified even for the same application architecture if different names are assigned to the routing path.

I'm willing to believe that there's a good use case for this, but I'd like to better understand the use case so we can consider multiple solutions to the problem -- this has worked well in other API design areas where the best solution ends up being inspired by someone else's thought.

[evankanderson]

To copy some options from slack:

Enterprise Integration Patterns suggests a Message History header which would continue to grow over time. You could express this as a JSON or semicolon-separated history list which would be fairly compatible with HTTP and Cloud Events.

[nicolaferraro]

Yeah, I should have mentioned what kind of "application" I'm talking about.
I agree that services, especially functions, should be as much as possible agnostic on how they are invoked, in order to improve composability.

I'm currently experimenting with the "glue" code that brings together services and compose workflows. In particular I'm trying to bind EIP developed with Apache Camel to Knative. That kind of glue code cannot be agnostic about sources, channels and consumers it needs to connect.

The problem I'm presenting here arises when you need e.g.

• to pair (zip) two events coming from two different channels into a single event
• to merge two streams of events into a single one, applying distinct transformations on each side
• ...

Distinguishing them by path is a option, but it does not seem possible with current API. Is it?

Btw, the channel header, also with message history, seems a much cleaner solution to me.

[evankanderson]

We don't currently have a path option, but it could be added to the addressable contract, and probably should be, along with some authentication options. A message-history based approach also seems feasible, though CloudEvents extensions seem to have some additional complexity around captialization and the intersection between JSON and HTTP headers (among others).

…

On Mon, Nov 26, 2018 at 9:25 PM Nicola Ferraro ***@***.***> wrote: Yeah, I should have mentioned what kind of "application" I'm talking about. I agree that services, especially functions, should be as much as possible agnostic on how they are invoked, in order to improve composability. I'm currently experimenting with the "glue" code that brings together services and compose workflows. In particular I'm trying to bind EIP developed with Apache Camel to Knatice. That kind of glue code cannot be agnostic about sources, channels and consumers it needs to connect. The problem I'm presenting here arises when you need e.g. - to pair (zip) two events coming from two different channels into a single event - to merge two streams of events into a single one, applying distinct transformations on each side - ... Distinguishing them by path is a option, but it does not seem possible with current API. Is it? Btw, the channel header, also with message history, seems a much cleaner solution to me. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#638 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHlyN_1chpKtrbmoVUIQrxiqcNmyqxTrks5uzMyugaJpZM4YzLsj> .

-- Evan Anderson <argent@google.com>