I've been trying to decide the mechanism for channels, and the type hierarchy...

This has been quite an ordeal, due to Java not allowing interfaces
to be hidden in a way visible to the entire application, but not public.
The other issue has been the denial of multiple extensions. The final
issue is that interfaces cannot have a mix of public and protected methods
(though why is fairly obvious). This means that I've had to use abstract
classes to represent the different parts of a channel.

The channel and operator interactions are a large part of this problem,
as I know the operators will desire quite a few methods within
the channels that I don't want to be publicly visible.

In particular, things like alts will need to be able to
register their interest in reading from many channels, and remove
that interest. However, this is asynchronous when the resources are locked,
and really shouldn't be tampered with by the user.

I didn't want to enable channels without those methods, since
otherwise the alts would have to cast the channels and hope no one
implemented their own! Yuck...

I could allow users to pass in waiting writers and readers of their own,
but it is a little dangerous...