Re: [srvx-devel] srvx 2.0 goals

[Entrope <en...@us...>]

Those all sound about right.  The only revisions I'd make are these:

- I added N2K (extended numeric) support to the 1.0 branch, too.  It's
been running on GamesNET -- just not using extended numerics yet.

- Part of the flexibility is to have "pluggable" services.  This means
that a network's admins can assign functions (or perhaps groups of
functions -- details can be worked out) to different bots.  This
satisfies the feature request, originally from AfterNET, of allowing
people to auth directly to ChanServ.

- Another goal would be to support DCC type connections.  It doesn't
fit nicely in with any of the groups Zoot listed (although it would be
a module that could be loaded or unloaded).

For I18N/L10N/NLS/whatever, that gets tricky.  Even if you look at
"nice" character coding schemes (ones that never use NUL bytes and
that have 1-to-1 ASCII characters), there are at least three different
ways to delineate characters on the wire.

Part of the problem (at least if we try to support CJK) is that
"different" characters are mapped to the same Unicode characters based
on similarities in meaning or form.  ("Different" in quotes because
the "average" outsider would say they are the same, but native
speakers insist that they are not.)  It would be bad to mis-translate
those if we make the core use one encoding (such as Unicode) and
transcode to and from that at srvx's "edge" (where it talks to IRC or
other things).

I don't know what, if any, MBCS systems are currently used on IRC.  If
there's only one, it might not be too hard to support it.  It'd be
even easier if we can use a fixed wide character set (like UCS-2 or
UCS-4) to provide NLS support.

-- Entrope