for chat david? c'mon. not everyone is ted turner.
especially when (last time i checked) most of the code was just
the dalnet ircd (the old one mind you, not the one [bahamut] that
jason referred to). stick to the free versions guys.
-ken harris.
Last time you checked? How could you have possibly checked ConferenceRoom's
code?
ConferenceRoom used to have a DreamForge protocol compatability mode. This
was useful a long time ago before there were any ConferenceRoom networks
large enough to allow load testing. As soon as WebChat/WebNet exceeded
10,000 users, the compatability mode was dumped in favor of extra features
that the old RFC1459-based server-server protocols couldn't possibly
support. Since that time, ConferenceRoom's chat layer was reimplemented
anyway, so there aren't even any remnants of that compatability.
There are no implementation similarities between Ircd and ConferenceRoom.
Ircd is written in C, ConferenceRoom is C++ and OOP from the ground up. Ircd
was written for UNIX with some patches to make it sort of work on Windows.
ConferenceRoom is written in platform-independent code that sits on an
operating system adaptation layer (including, for example, completion ports
for Windows and /dev/poll support for Solaris). Ircd is fundamentally
single-threaded with a select or poll loop, ConferenceRoom is multithreaded
with a thread pool architecture.
A lot of ConferenceRoom customers started out with Ircd as a proof of
concept implementation. At some point they needed features and support that
it's just not really possible to get with Ircd. The list of ConferenceRoom
features that are nearly impossible to get with Ircd and Apache would run
for several pages.
Ircd has openness built in from the ground up. For a public chat network,
that's really great. However, for an application where you need more control
and integration, Ircd becomes really unworkable. (For example, how easy is
it to integrate Ircd with a web site? Or with customized security rules?)
Services is a partial kludge to get some fraction of that capability, but
it's not something I'd want to rely on. You can fake a lot of things with an
assortment of special-purpose bots as well. But you wind up with a
hodge-podge of CGIs, bots, and other assorted bits and pieces that you can
only support yourself.
Just try to get Ircd to perform reasonably on an NT4.0 or Win2K server. Try
to get it to take advantage of a multiprocessor Solaris box. Ted Turner
wants a better solution than that. 
David Schwartz
PS: If you want to continue this off-list, I'd be happy to correct any
further misconceptions you might have. But this has almost no relationship
to network operations.
