Customizable message header keys rather than constant keys

[payam-alexander]

Hi @mookid8000 ,
There must be other people who have had to deal with legacy systems and to integrate them with a newly built application with rebus.
In some scenarios older systems might not be much integrate-able with rebus if rebus insists to have it's own message headers.

Now, would you be open to the idea of having an injectable contract and implementation of IHeaderProvider so it can be customizable (Decorateable) in the consumer of rebus?

If that's palatable for the moderators, I am more than happy to contribute with the full solution to rebus itself and other repos like rebus.rabbitmq.

[mookid8000]

It was never the intention (at least not from me) to make it possible for Rebus to consume messages sent from non-Rebus systems. I always recommend people that they use Rebus to communicate with Rebus, and treat all sorts of integration scenarios as exactly that: Integration scenarios!

I mean, maybe we could extend Rebus to allow for mapping headers back and forth, and then maybe we could configure it somehow fill in missing headers via some kind of logic, etc etc, BUT my fear would be that the list of desired features would never end.

My own experience is that it's usually not TOO hard to write channel adapters at the periphery, which will simply forward their contents as proper Rebus messages and/or forward Rebus messages as some kind of externally consumable format.

That's just my 5 cents. Feel free to try to convince me 🙂