(Draft) Introduction

Let me start out by saying this proposal doesn't propose that support be dropped for IMultithreaded* interfaces. This proposal does propose that they should be marked as deprecated and over time channels should be rewritten to use IChannel instead. Also, we need to make it clear that IMultithreaded* channels shouldn't be perceived as a better, faster more optimized way of developing a channel.

Drawbacks

Complexity

That implementing Channels implemented as IMultithreaded* makes for are much more complex code than normal IChannels with the same features. This is a serious problem in an open source project. It is a very serious barrier to collaboration, and this reason alone is enough to warrant deprecation.

In addition to the unneeded complexity there are some other problems with IMultithreaded* channels:

No Session Replication

They won't work with session replication as the static state map won't be serialized and replicated.

...

They require the channel's implementation to remove objects from its map when a user's session is removed. This easily results in a channel that leaks memory if it fails to remove the objects from its map.

Less Diagnostic Information

IMultithreaded* channel's also can't print out much useful information in their toString() methods to let us know what is going on when a
channel fails to render. IChannels can provide all the relevant information needed to diagnose a rendering failure including which user
the problem occurred with and what the publish/subscribe id of the channel is. IMultithreaded* would need to be modified to have a method
toString(uid) that would take the user's session/uid as a parameter in order to print out the same useful information.

...