[
https://issues.apache.org/jira/browse/THRIFT-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16764403#comment-16764403
]
James E. King III commented on THRIFT-4667:
-------------------------------------------
I'd have no problem aligning the TMultiplexedProcessors across languages to:
1. Provide the "default processor" like Java does. This allows older non-multi
clients to connect and issue requests and get something processed. It provides
a nice upgrade path for the server to add multiplexed on the same port with the
same underlying protocol.
2. Provide an unregister mechanism as you suggested. It makes sense to me. A
good use case for this would be if someone had an API where they modify
security privileges; the server might need to remove some of their API access
by disabling services.
Pull requests welcome. Suggest you do it on netstd, since netcore and csharp
are deprecated.
> netcore TMultiplexedProcessor derived processors
> ------------------------------------------------
>
> Key: THRIFT-4667
> URL: https://issues.apache.org/jira/browse/THRIFT-4667
> Project: Thrift
> Issue Type: Improvement
> Components: netcore - Library
> Affects Versions: 0.11.0
> Reporter: J W
> Priority: Minor
>
> Currently we maintain a local version of Thrift because we added an
> `UnregisterProcessor()` method to `TMultiplexedProcessor`. It looks like
> adding this method would break symmetry with the "multiplexed processor"
> found in other languages' implementations.
>
> Instead, how about changing `_serviceProcessorMap` to `protected` so library
> users can create classes that inherit from `TMultiplexedProcessor`?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
