[
https://issues.apache.org/jira/browse/DISPATCH-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186565#comment-17186565
]
Robbie Gemmell commented on DISPATCH-1765:
------------------------------------------
{quote}
we added a new feature in this release
{quote}
'This release' being 1.13.0? In which case that would need special-cased with
the existing mechanism, or support being dropped for using the feature between
such old 1.13.0 and newer routers.
{quote}
So as you pointed out the correct way of implementing this would be to put the
capability in both the desired and offered fields in the Open frame. Previous
releases of the router code never checked these fields so there's no risk in
that approach.
{quote}
To be clear, I mean one peer needs to desire it, and the other needs to offer
it. It depends on a given functionality whether each of them both offering and
desiring it makes sense. In this case, it might make sense to do both, if e.g
these 'additional links' can be initiated in both directions between routers.
Though, you can optimise when 'replying' to an Open; you needn't offer
something the peer didn't desire.
{quote}
Would you agree that having the router set these capabilities when connecting
to non-router endpoints should be safe as well, as a generic endpoint should
ignore offered/desired capabilities it does not recognize? I'm thinking of
setting the capability regardless of what kind of peer the router is connected
to in order to allow any endpoint the option of accepting additional links if
desired.
{quote}
There should be no harm in desiring or offering a capability, if there were the
affected peer is broken and needs fixed.
> Router version parsing is broken
> --------------------------------
>
> Key: DISPATCH-1765
> URL: https://issues.apache.org/jira/browse/DISPATCH-1765
> Project: Qpid Dispatch
> Issue Type: Bug
> Affects Versions: 1.13.0
> Reporter: Ken Giusti
> Assignee: Ken Giusti
> Priority: Major
> Fix For: 1.14.0
>
>
> The version string advertised by the router in the Open performative may be
> parsed incorrectly if a non-semantic format is used (e.g. a git commit sha).
> Currently the router uses the router version of its peer in order to
> determine if the peer supports certain features like streaming links.
> Two changes proposed to solve this:
> 1) do not attempt to parse the version string arriving in the Open
> performative. Treat it as opaque ascii data.
> 2) Add router-defined capabilities and advertise them in the
> offered-capabilities field of the Open performative.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
