|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: Instant chats and central servers
> 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.
|