[
https://issues.apache.org/jira/browse/DISPATCH-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16337744#comment-16337744
]
ASF GitHub Bot commented on DISPATCH-89:
----------------------------------------
Github user kgiusti commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/244#discussion_r163577138
--- Diff: python/qpid_dispatch/management/qdrouter.json ---
@@ -1126,6 +1126,106 @@
}
},
+ "router.config.exchange": {
+ "description":"[EXPERIMENTAL] Defines a topic exchange.",
+ "extends": "configurationEntity",
+ "operations": ["CREATE", "DELETE"],
+ "attributes": {
+ "address": {
--- End diff --
I don't think there really is any consistency - we've had
'router.config.address' and 'router.address' types from the beginning, not
'router.config.addr' etc. The compound attribute names do use "Addr" as part
of the name (while I don't like that either), but when there's a single address
attribute it's either "addr" (router.config.autolink) or "address"
(router.node). There are only two cases so consistency hasn't been established.
I just don't like the "addr" contraction in the user-facing API (and this
includes <prefix>Addr names). We use "addr" all over the _code_ as a shortcut
for "address", and I think using "addr" for autolink just seemed natural to us
programmers. But for a non-programmer does dropping the "ess" help in any way?
I feel like I'm bikeshedding this. Are there any other folks that feel
strongly either way? I'll do whatever the consensus is.
> Model the legacy topic exchange behavior of qpidd
> -------------------------------------------------
>
> Key: DISPATCH-89
> URL: https://issues.apache.org/jira/browse/DISPATCH-89
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Routing Engine
> Affects Versions: 0.2
> Reporter: Ken Giusti
> Assignee: Ken Giusti
> Priority: Major
>
> With Qpidd, a user can define a binding from an Exchange to a target queue.
> The binding uses a key that is compared to a message's subject field. If the
> key matches, the message is routed to the target queue for that binding.
> It should be possible to emulate this behavior using the dispatch router.
> Example:
> User defines a mappings from a target address (the 'exchange') to a different
> target address(es) (the 'queue'). These mappings (the 'bindings') are driven
> by a pattern match against the inbound message's subject field.
> Messages arriving at the router from any link whose target address has
> bindings defined are not immediately routed. Prior to routing, the message's
> subject field is extracted and compared against each binding defined for the
> target. A list of new target addresses is created containing the target
> address from each binding that satisfied the pattern match. The message is
> then routed to each new target address.
> The pattern syntax should be the same 'dotted string' notation from qpidd,
> including '*' and "#' wildcarding.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
