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.
That implementing Channels as IMultithreaded* makes for *much more
complex code* 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:
They won't work with session replication as the 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.
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.
What makes this even more clear-cut for me is that *we haven't written a
single channel that benefits from being implemented in this obscuficated
way know as IMultithreaded*. It is clear that we should discourage
implementation of channels as IMultithreaded*, and I think deprecating
the interfaces is the clearest way to communicate this without
ambiguity.