In order to efficiently implement filtering of Hedwig messages, Hedwig should be able to rely on metadata information. (i.e. without needing to deserialize the content of the message)
Filtering could use a subset of SQL (like in the JMS spec), leading to queries such as :
"header1 like 'a' AND header2 IS NOT NULL"
For that purpose, I propose to add customizable metadata to the definition of Hedwig messages, as header fields.
Metadata must be customizable because it may be arbitrary. We should provide "map-like" containers according to the type of the metadata field. Metadata fields would be accessed by name.
There are predefined headers for JMS that could be added as metadata fields such as : destination (~topic), delivery mode (persistent or not), expiration, priority, timestamp, correlation id (link to other message), reply to, type and redelivered. I think only a subset of these should be predefined headers, if any.
Adding metadata fields to Hedwig messages implies modifying the message definition, which does not break backward compatibility when those fields are added as optional in the protocol buffer definition.