[crossfire] Moving server towards a modularized system?

[Brendan Lally]

On 1/28/06, Yann Chachkoff <yann.chachkoff at myrealbox.com> wrote:
> I'm not speaking about "theoretical developers" - I'm speaking about those who (hopefully) will still play with crossfire and its code long after we don't. I'm thinking about all the ideas that could get implemented much more easily on a cleaner base than on a patchwork of code.
>

I'd be inclined to say that the quickest way to do that would be to
have a deliberate compatibility break, not completely, but at least
back to what is actually used. Debian Stable is probably the single
most obsolete GNU/Linux distro in widespread use, but even this ships
crossfire 1.7.0

Given that crossfire 1.9 should be close to release (maybe?) the
second digit would wrap round, and the next release after that would
logically be 2.0. A major version number shift would be a reasonable
time to deliberately break compatibility with all versions below 1.7
(and maybe include some metaserver filter to stop servers older than
this being included too).

If this were to occur there would be an awful lot on the server side
that could be dispensed with

the map command and map1 commands (map1a could be used exclusively)
the item1 command (the C clients have long since used item2)
spell conversion from the old spell system
support for the old skill system.
support for oldsocket mode (pippijn recently made a textmode parser
using the modern packet structure, oldsocketmode is a hack that could
be retired completely)
doubtless there are more that I haven't thought of.

Remove all that compatibility cruft first, and then, when the server
is made leaner as a result, look at what, if anything needs
simplifying.

(note also, I would suggest taking the same approach with the C
clients, which have a similar problem (though less acutely))