[
https://issues.apache.org/jira/browse/THRIFT-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17031070#comment-17031070
]
Jens Geyer edited comment on THRIFT-5084 at 2/5/20 9:52 PM:
------------------------------------------------------------
a) Why is adding a protocol a breaking change?
b) Is there a "default" mechanism that can be used to redirect old
(non-multiplex) clients to one of the services to act as a compatibility
fallback?
was (Author: jensg):
Why is adding a protocol a breaking change?
> 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: Breaking-Change, 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)
