[
https://issues.apache.org/jira/browse/THRIFT-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17031397#comment-17031397
]
Alexander Edge commented on THRIFT-5084:
----------------------------------------
Hi Jens, thanks for your reply. My answers:
a) I've had a second look at this and it is not a breaking change after all. I
was concerned that changing the {{TProcessor}} protocol would break existing
builds, but it's not the case. I have removed the label.
b) Yes, I have added the option of a default processor on
{{MultiplexedProcessor }}which is used when a non-multiplexed message is
received. It can be initialised with one or registered after initialisation. It
will throw an error if no default processor is registered and a non-multiplexed
message is received.
> Swift: Server-side support for Multiplexing Services
> ----------------------------------------------------
>
> Key: THRIFT-5084
> URL: https://issues.apache.org/jira/browse/THRIFT-5084
> Project: Thrift
> Issue Type: Improvement
> Components: Swift - Library
> Affects Versions: 0.13.0
> Reporter: Alexander Edge
> Priority: Minor
> Labels: multiplex
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The Swift library features {{TMultiplexedProtocol}} but not
> {{TMultiplexedProcessor}}, which is required for use server-side.
> I've added {{TMultiplexedProcessor}}, following the same patterns as the
> other language libraries. I've marked this issue as _Breaking-Change_ since
> it removes the {{associatedType}} from the {{TProcessor}} protocol. Since the
> existing {{TProcessor}} definition uses an {{associatedType, it makes it
> impossible for TMultiplexedProcessor}} to implement {{TProcessor}}. By
> definition it should support processors of multiple services, not a single
> service.
> I've added tests which require a change to {{Package.swift}} to run using
> {{swift test}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
