[srvx-devel] srvx 2.0 goals

[Zoot <zo...@pl...>]

The srvx development team has been considering a possible rewrite of
srvx, tentatively dubbed version 2.0; many ideas have been collected,
discussed, and dissected by the developers and many suggestions
received. Presented here are the most important goals I see for srvx
2.0, though this list is far from comprehensive. Please toss in anything
you'd like to see in srvx 2.0 regardless of how crazy you think it
sounds; we want srvx 2.0 to be the best services on Earth.

Throw in anything that comes to you, unless it has anything to do with
flying butt monkeys, crumpets, or putting a man on the Moon.

Efficiency:
srvx 2.0 should be as efficient, yet portable, as possible. The limiting
factor here will likely be the database and network infrastructure.
Modern processors shouldn't have a problem with most of srvx's
requirements. Keep in mind that srvx's current stable version sips CPU;
we have plenty of free CPU in our "budget" to spend on features before
there's cause for concern.

Scalability:
GamesNET, the primary sponsor of srvx development, currently peaks at
around twelve thousand users and is growing rapidly. srvx must support
whatever is necessary to store, index, and service at least up to the
twenty five thousand user range. This shouldn't be a problem, as Entrope
has added ircu N2K support to srvx 1.1. The rest of srvx must scale as
well, which also likely will not be a problem. Scalability above twenty
five thousand users should be considered as well.

Flexible:
We agree module support and robust runtime configuration changes are
required; srvx 2.0 can be as slim or bloated as the administrator wants.
Virtually everything that is not a core service should be a module,
including protocol support. If this were taken to an extreme, the core
itself could be modularized, though this would introduce problems of its
own. Fostering a community of quality 3rd party module developers (as
well as people who hack the srvx 2.0 core) is important.

Fault Tolerance:
Previously discussed on the "next generation database approach" thread.
We want replication of critical data and durable storage. This also
factors into other portions of srvx's design; srvx could be partitioned
in some way that services or modules are isolated from bugs in other
services or modules, if possible. For example, proxy checking
functionality is a relatively isolated task (hook client connections,
scan connecting hosts, gline hosts that fail the tests) that could be
moved out of process. This actually has two benefits: bugs in the proxy
checker don't take down other vital services, and proxy checking can be
off-loaded onto another machine (or perhaps several, at different
locations, so European users are scanned by a European proxy checking
installation).

User and Administrator Friendly:
This subjective criteria will be difficult to measure, but users should
have as simple or complicated an interface as they can tolerate.
Administration doesn't have to be duh-stupid, but it should "just work".
This is primarily an issue for the services maintainers, and discussion
could be postponed until the core has been completed or is reasonably
stable and work on the services begins.

Native Language Support:
GamesNET is no longer the United States-and-Canandadia-centric network
it used to be; therefore, srvx help files, status/response messages, log
entries, and documentation should be available in multiple languages.
Dates, numbers, and times should be formatted according to local
standards.

The IRC RFC doesn't make any mention of Unicode or internationalization
issues in general, and I don't think there are any emerging standards
regarding Unicode and IRC with the exception of Andy Church's IRC 3
proposal; however, it's worth considering the nightmare that is Unicode
support.

Web Integration:
srvx must have some sort of facility to allow web integration, the
nature of which we need to discuss. This is a ripe topic for a big ol'
separate thread on this list.

Backwards Compatibility:
We need to provide tools and documentation to help users of srvx 1.x
migrate their databases and settings to srvx 2.0.

Minor Changes:
srvx's database, log, help, and pid paths should be configurable.

And they lived happily ever after.

The End.

# Zoot