[
https://issues.apache.org/jira/browse/PROTON-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18088109#comment-18088109
]
ASF subversion and git services commented on PROTON-2873:
---------------------------------------------------------
Commit e64c9fada89a940448fdf578c01a4e57f2c34844 in qpid-proton's branch
refs/heads/main from Andrew Stitcher
[ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=e64c9fada ]
PROTON-2873: Work around transacted modified dispositions
The disposition API currently gives no access to the nested outcome of a
transacted modified disposition - however the usual case has the
delivery-failed boolean set for this disposition and this is the default
behaviour for this disposition (otherwise the release disposition could
be used instead in most cases). So we need to work around this until we
have a better fix:
- When fix a transacted modified outcome to be delivery-failed and
redeliverable on the wire.
- In the example python broker we assume that any received transacted modify
will be failed delivery, redeliverable.
- In the C++ API we change the processing of modify to allow transacted
modifies to work.
> Reorganize delivery disposition API and representation
> ------------------------------------------------------
>
> Key: PROTON-2873
> URL: https://issues.apache.org/jira/browse/PROTON-2873
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
> Affects Versions: proton-c-0.40.0
> Reporter: Andrew Stitcher
> Assignee: Andrew Stitcher
> Priority: Major
> Fix For: proton-c-0.41.0
>
>
> The internal representation and modelling for delivery dispositions is
> significantly different from the model of dispositions in the AMQP spec.
> One case in point causes the disposition representation to use more space
> than necessary as every field in every possible type of disposition is
> present. A better representation would be a union of the different
> disposistion types so that only the needed fields of whichever specific type
> of disposition is being used is present.
> For the present this would need to be additional APIs to maintain backwards
> compatibility. But the current disposition API should be deprecated and could
> be removed for a 1.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
