[ https://issues.apache.org/jira/browse/BOOKKEEPER-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13409504#comment-13409504 ]
Mridul Muralidharan commented on BOOKKEEPER-309: ------------------------------------------------ bq. as I described on BOOKKEEPER-78 ( https://issues.apache.org/jira/browse/BOOKKEEPER-78?focusedCommentId=13403094&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13403094 ), different protocols could leverage a system property 'messageType' in MessageHeader to know how to encode/decode the data according to its protocol. I think it could resolve interoperability issue you care about. I am not sure if I am conveying what I mean by interoperability adequately : but I will give one more shot. Consider HTTP for example - a firewall or proxy does not need to understand anything about what is contained within the http response body to make decisions about it : it does so via the status and headers. Similarly a lot of clients which consume http. Those two aspects form the basis for interoperability between diverse users of http protocol (which also describes what the body is btw). The proposal in hedwig right now require a wire-level understanding of how the message header is encoded : with different clients doing so differently. headers can be the generic means for different - potentially incompatible clients - to interact in an interoperable manner. Think OCP. Filters are an example of it - specify a filter which says deliver only messages with a specific set of constraints satisfied (including user specific headers) - in a decoupled manner : with different clients requiring different ways of interpreting what the constraints for it are. Please note that this is orthogonal to using different topic's for different usecases. The SQL-like syntax supported in JMS spec for filtering also follows similar rationale : Have typed headers, define how to filter them using SQL, and rely on provider/server to deliver only messages that a client can actually use/interpret/needs from the Topic(s) subscribed to. message type is just one way (though crucial) way in which clients interoperate (jmsBodyType iirc), but there are others and potentially user specific means to do so. If hedwig does not require this sort of extensibility, then ofcourse the discussion is moot : and it makes logical sense to go with application level headers. bq. actually we just finished the message filter work and I would attach the patches these two days to let you see whether it makes sense for you or not. Great ! I will watch that issue for updates. Thanks ! Greate ! > Protocol changes in hedwig to support JMS spec > ---------------------------------------------- > > Key: BOOKKEEPER-309 > URL: https://issues.apache.org/jira/browse/BOOKKEEPER-309 > Project: Bookkeeper > Issue Type: Sub-task > Reporter: Mridul Muralidharan > Attachments: hedwig-protocol.patch, hedwig-protocol.patch.1 > > > JMS spec compliance requires three changes to the protocol. > a) Support for message properties. > b) Make body optional (message contains only properties). > c) Return the published message's seq-id in the response. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira