Magick II was started because the original Magick I was buckling under the strain of large networks due to the fact it was based on EsperNet code, which wasnt designed for such large loads -- especially with all the modifications that had been added to it by the time it reached Magick 1.4. The decision was made after 1.4 that a total re-write was in order. So I got together with my co-programmer, Bill King, and we started hammering out how we should go about it. Bill thought it would be best if it was re-written in C++. I didn' know much C++, so I went off to learn C++, while he started trying to convert the existing code to C++.
In the end, the effort to try and convert the existing Magick code to C++ was scrapped, and we went right back to square one, re-writing EVERYTHING by hand, no function would be left unturned. For this, Bill went off to find some libraries that would make this thing easier to write, while I worked out some kind of overall design spec. Magick II was designed to be easily portable across platforms, to be multi-threaded (i.e. able to make use of multiple CPU's in a box), and be efficient enough that it could handle any load thrown at it. ACE met our requirements, and we started building Magick around it.
As time went on, other requirements developed -- things like it should be totally multilingual (including all responses to users, help files, and the log file). It should have some kind of system in place so we can trace the programs execution in case of a problem that doesnt coredump, without having to add masses of code to figure it out. Originally I was working the UNIX side, Bill was working the Windows side.
Before the product even hit BETA, we would break both EGCS and MicroSoft Visual C++ 5.0, and move onto things like GCC 2.95, and Borland 4.0 respectively. We would also surpass the limitations of the STL string, and re-write it, and encounter - and overcome many more boundaries. Now days Magick II is incredibly intensive to compile and requires fairly modern compilers, but the result is very efficient, and users notice.
Magick also supports such things as encryption and compression of the databases (which are only the beginning of its security features!), different IRC Daemons, multiple languages and timezones, DCC file transfers, alot of the more advanced bandwidth saving tecniques supported by IRC Daemons, in-line code tracing that can be turned on or off, multiple threads to take advantage of multiple CPU's, and a whole host of new features that users, admins, and services staff will all notice alike. And we have only scratched the tip of the iceberg.
In the future, we have some very big plans for Magick II. This includes things like a full scripting language (that enables you to do anything from re-bind a command to a different access requirement, to creating your own commands, to adding a new piece of data to the database, to adding your own entire service!), being able to directly link Magick services and share databases between them - even the ability for a set of services thats too lagged to let another set take over, and implementing a full GUI to remotely configure and monitor Magick from. We're in for an interesting ride with Magick II...
- PreZ
|
