[
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
