Fw: [srvx-devel] srvx 2.0 goals

[R. B. S. <de...@vt...>]

Here ya go.

-def

----- Original Message ----- 
From: "Zoot" <zo...@pl...>
To: "srvx-devel" <srv...@li...>
Sent: Monday, January 21, 2002 7:15 PM
Subject: [srvx-devel] srvx 2.0 goals


> 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
> 
> 
> _______________________________________________
> srvx-devel mailing list
> srv...@li...
> https://lists.sourceforge.net/lists/listinfo/srvx-devel