srvx-devel Mailing List for srvx IRC Services (Page 2)
Brought to you by:
entrope
Menu
▾
▴
srvx-devel — srvx development discussion
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(15) |
Feb
(2) |
Mar
(6) |
Apr
(3) |
May
(7) |
Jun
(4) |
Jul
(1) |
Aug
(4) |
Sep
|
Oct
(5) |
Nov
(2) |
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Entrope <en...@us...> - 2002-05-04 16:48:57
|
All the juicy details are in the email to srvx-announce and in changes.php. The tag in CVS for the released files is rel-1_1. I'll probably let it sit for a few days to see what bugs crop up, then make a branch for 1.2 development. (And boy is that going to have ugly revision numbers. :) The main goal of 1.2 is going to be support for talking to Bahamut servers. It will also end up with some tweaks to HelpServ and probably how the email stuff works, depending on how things go for GamesNET and other networks that deploy 1.1. -- Entrope |
|
From: Res <re...@au...> - 2002-04-14 22:27:40
|
Hi, Unfortunately no, I removed all prior entires, shuteverything down to make sure nothing was hanging around, and added as you suggested, still warns at 3... Regards Res On Sun, 14 Apr 2002, Zoot wrote: > I believe the problem is that you're adding trusts for *@host.com where > the addtrust command expects just host.com. For example, "addtrust > shell.auschat.net 10 1M Reason here." should allow 10 users on for a > month from that host. |
|
From: Zoot <zo...@pl...> - 2002-04-14 19:25:42
|
Hello, > What I have tried on there own and all at same time : > > -OpServ- *@*auschat.net (limit 99, expires 2 > years, and 8 months: Local) > -OpServ- *@shell.auschat.net (limit 99, expires 2 > years, and 8 months: Admin) [snip] > [msg(opserv)] addtrust *@192.168.* 99 5555555555 Local > -OpServ- Added trusted hosts to the trusted-hosts list. I believe the problem is that you're adding trusts for *@host.com where the addtrust command expects just host.com. For example, "addtrust shell.auschat.net 10 1M Reason here." should allow 10 users on for a month from that host. I hope this fixes the problem you're experiencing. # Zoot |
|
From: Res <re...@au...> - 2002-04-13 23:39:25
|
Hi, On 13 Apr 2002 en...@us... wrote: > I'm not sure I follow the question. Which trigger do you mean? To > sort of ask the silly basics: What are you sending srvx, what does it > do, and what do you expect it to do differently? Thank you, Ok...the trigger is the " trusted users " function so *X* number of clients (say on a shell box) are able to use the server safely Scene: I want to allow *X* number hosts on shell.auschat.net to use our local ircd on a WLAN. Y/I-lines are set to allow such. OpServ is told 4 clones maximum. I have added and tried in different configurations but Opserv is still warning at 3 and G-lines at 4 from the hostmark. What I have tried on there own and all at same time : -OpServ- *@*auschat.net (limit 99, expires 2 years, and 8 months: Local) -OpServ- *@shell.auschat.net (limit 99, expires 2 years, and 8 months: Admin) One I'm trying now for you...as previously I did not try direct IP's This is in addition to the above hostmarks being in there.. [msg(opserv)] addtrust *@192.168.* 99 5555555555 Local -OpServ- Added trusted hosts to the trusted-hosts list. [msg(opserv)] writeall -OpServ- All db write completed (in 0.009 seconds). ### Ok I have 3 conenctions then -OpServ- WARNING: You have connected the maximum permitted number of clients from one IP address (clones). If you connect any more, your host will be banned from the network. ### Now number 4 *** Excessive connections from a single host.. [09:32am][<Nickname not registered yet>] [] .....and I'm outa there :) As above it still glines them, even after shutdown, reloads, restarts of all servers. The STATS command as above shows it knows them, it just doesn't seem to honour them. It may be something I have mistakenly overlooked, if it is I'm sure you'll appreciativley point it out. Additional info: -OpServ- srvx 1.0.3 (prodigy), Built: Mar 24 2002, 18:59:37. IRCD u2.10.10.pl18.(release) If you require any more info I've neglected to include please don't hesitate to email me. Regards Noel |
|
From: Entrope <en...@us...> - 2002-03-27 17:52:25
|
hunnr talked to me earlier today; that's why I was pushing to get 1.1 done soon. It could take longer to code and test both sets of things together than doing them one after another. Basically we'd have to redo some of the earlier changes to support multiple protocols -- but since we've done it before, most of the changes (outside of proto.c and parse.c) are known. It just won't be pretty :) One of the first steps is going to be to see what additional commands (or other syntax) Bahamut uses for services' interaction with the rest of the network. Things like ircd/Undernet's ACCOUNT command, the different user and channel modes, etc. I was planning on doing that today or tomorrow. -- Entrope "R. Brenton Strickler" <ris...@vt...> writes: > I hate to throw this in the mix, but we're starting to seriously consider > bahamut now. Run's reasoning for switching was that we were more production > oriented and he was looking for a more development oriented network. No > hard feelings there I suppose. Anyways, what needs to be done to implement > another protocol? > > -def > > ----- Original Message ----- > From: "Entrope" <en...@us...> > To: <srv...@li...> > Sent: Wednesday, March 27, 2002 10:18 AM > Subject: [srvx-devel] getting srvx-1.1 out the door > > > > I'd like to make a push the next two weeks or so to get srvx 1.1 > > finished and start testing the new code. Most of the "finish it" code > > is HelpServ, although there are a few other minor features that can be > > done (listed below). Do people (in particular the other developers :) > > have time that they can commit to helping us get to a shipping state? > > > > Minor TODOs: > > - Disallow !(ejectuser) *!*@* > > - Optionally send a message to a new channel's owner after !register > > - Don't fight over /TOPIC (and/or /MODES) if setter is +k. > > - ?trace gline channel -#foo (or +#foo or @#foo), to gline everyone in > > #foo with neither voice nor ops (or with voice and no ops, or ops, > > respectively) > > - (maybe) Option to kickban users joining channel who aren't on userlist > > - (maybe) "?collide nick username@host description" instead of "username > host" > > Anything else? > > > > -- Entrope > > > > _______________________________________________ > > srvx-devel mailing list > > srv...@li... > > https://lists.sourceforge.net/lists/listinfo/srvx-devel > > > _______________________________________________ > srvx-devel mailing list > srv...@li... > https://lists.sourceforge.net/lists/listinfo/srvx-devel |
|
From: R. B. S. <ris...@vt...> - 2002-03-27 16:43:00
|
I hate to throw this in the mix, but we're starting to seriously consider bahamut now. Run's reasoning for switching was that we were more production oriented and he was looking for a more development oriented network. No hard feelings there I suppose. Anyways, what needs to be done to implement another protocol? -def ----- Original Message ----- From: "Entrope" <en...@us...> To: <srv...@li...> Sent: Wednesday, March 27, 2002 10:18 AM Subject: [srvx-devel] getting srvx-1.1 out the door > I'd like to make a push the next two weeks or so to get srvx 1.1 > finished and start testing the new code. Most of the "finish it" code > is HelpServ, although there are a few other minor features that can be > done (listed below). Do people (in particular the other developers :) > have time that they can commit to helping us get to a shipping state? > > Minor TODOs: > - Disallow !(ejectuser) *!*@* > - Optionally send a message to a new channel's owner after !register > - Don't fight over /TOPIC (and/or /MODES) if setter is +k. > - ?trace gline channel -#foo (or +#foo or @#foo), to gline everyone in > #foo with neither voice nor ops (or with voice and no ops, or ops, > respectively) > - (maybe) Option to kickban users joining channel who aren't on userlist > - (maybe) "?collide nick username@host description" instead of "username host" > Anything else? > > -- Entrope > > _______________________________________________ > srvx-devel mailing list > srv...@li... > https://lists.sourceforge.net/lists/listinfo/srvx-devel |
|
From: Entrope <en...@us...> - 2002-03-27 15:16:02
|
I'd like to make a push the next two weeks or so to get srvx 1.1 finished and start testing the new code. Most of the "finish it" code is HelpServ, although there are a few other minor features that can be done (listed below). Do people (in particular the other developers :) have time that they can commit to helping us get to a shipping state? Minor TODOs: - Disallow !(ejectuser) *!*@* - Optionally send a message to a new channel's owner after !register - Don't fight over /TOPIC (and/or /MODES) if setter is +k. - ?trace gline channel -#foo (or +#foo or @#foo), to gline everyone in #foo with neither voice nor ops (or with voice and no ops, or ops, respectively) - (maybe) Option to kickban users joining channel who aren't on userlist - (maybe) "?collide nick username@host description" instead of "username host" Anything else? -- Entrope |
|
From: Byte <by...@fu...> - 2002-03-08 10:25:40
|
I'll aim for it appearing in 1.2.x then? It could [probabaly not] easily have a 'friends' list and restrict the number of messages you can have stored. --Byte |
|
From: Entrope <en...@us...> - 2002-03-07 14:28:41
|
You're welcome to work on one -- I don't think anyone has started on an implementation yet. Unless it's done very quickly, though, it won't be in the 1.1.0 release. (Speaking unofficially, it would probably disabled or restricted to staff on GamesNET anyway. But other networks might find it useful. :) -- Entrope |
|
From: Byte <by...@fu...> - 2002-03-07 14:00:40
|
Has anyone started memoserv for 1.1.x? I'm thinking of trying to make one by looking at the current HelpServ. --Byte |
|
From: Entrope <en...@us...> - 2002-02-14 14:37:21
|
Hello, why do you send this to the development mailing list? Would it require (in any way) capabilities that "network helpers" do not have? Or is it just a policy issue that should be taken up with GamesNET's support staff? -- Entrope |
|
From: Byte <by...@fu...> - 2002-02-14 14:16:41
|
Zoot wrote: I'd like to point out that as helpers climb the ladder, they shouldn't simply be given more permissions and yet be responsible for the same old, routine duties. Helpers might start out in #support, but they should be given new and different jobs as they advance; for example, they could be appointed to police channels that request a helper's presence. (Say, busy channels that suffer lots of lamers, or release parties/events, etc.) I agree, the helpers do not get enough motivation. They need more interesting things to do other than help other users. Letting them help in busy channels like that would be good. --Byte |
|
From: Zoot <zo...@pl...> - 2002-01-25 17:20:36
|
Looking at this from the technical standpoint, implementing the scheme you suggested should be easy, but I wonder if this is really the solution to the general problem of keeping helpers in line. Currently, helpers with security override have virtually the same access to ChanServ as full opers, yet most handle a relatively small set of problems: users want general IRC or GamesNET help, they want their handles opened so they can authenticate, or they want to register a channel. Perhaps the level one helpers could have access to only the commands necessary to handle those problems, while level two helpers have full security override. I don't want to tell the support committee what to do, but I think it's a reasonable suggestion. A hierarchy of helpers would be great. I'd like to point out that as helpers climb the ladder, they shouldn't simply be given more permissions and yet be responsible for the same old, routine duties. Helpers might start out in #support, but they should be given new and different jobs as they advance; for example, they could be appointed to police channels that request a helper's presence. (Say, busy channels that suffer lots of lamers, or release parties/events, etc.) A hunger for power can be a healthy motivator, but I'm not sure that we want people whose only motivation is to get that O:line. A better motivation is that they enjoy what they're doing. (I know I like working on srvx, for example -- if all I was getting out of it was the hassle of an O:line and a front row seat to network politics, I'd be gone in a second.) I'm sure there are lots of interesting aspects of network operation that the helpers would really, truly be happy to handle, given the appropriate helpers get the job. Heck, I'm sure every committee, including routing, development, web, services, PR, has some work or project that hasn't been getting attention for lack of time or people: let the helpers apply for the job! They can get the sense they really are contributing. Right now, it seems this needs immediate fixing. If we'll be kludging up a quick fix, we would need to know what each level does and doesn't have access to. For 2.0, I'd really like a more general solution that doesn't require new code to implement new and different access control schemes; new "levels" of helpers could be created and existing levels modified, and authorization would be completely unified across all services. I'll be writing up a proposal later today. I'm sorry this turned into another essay, oops. # Zoot |
|
From: Mike K. <ka...@gl...> - 2002-01-23 19:46:53
|
Our reasoning for the 2 levels is simple, for one, it would serve as = motivation for the helpers to continue putting in hours. As of right = now, the only motivation they have is 1. keep their job, and 2. get an = O:line. They all know getting an O:line is not likely, and it takes a = LONG time to earn one. This would not only give us an alternative goal = for motivation, but would most likely improve their time spent in = #support.=20 Along with that, it would give us a way to distinguish helpers that put = a lot of time in, from helpers that are less active / less valuable. = Kind of a way to show we know and appreciate the knowledge / time they = put forth for us.=20 We also believe it would further encourage the staff to help in = #support, because at the very least, they have something to work = towards.=20 This was the best way we came up with to handle the situation, We would = be happy to accept new ideas, if you feel they would possibly do the job = better. ---- Kaz (Ka...@Ga...) GamesNET Support Admin Http://www.GamesNET.net |
|
From: R. B. S. <de...@vt...> - 2002-01-23 04:54:33
|
I think it would help the design process a bit if we knew your reasoning = for that. We could have alternative suggestions that you may not have = thought about that would work even better. -def ----- Original Message -----=20 From: Mike Kaczmarczyk=20 To: srv...@li...=20 Sent: Tuesday, January 22, 2002 8:34 PM Subject: [srvx-devel] Support Additions What we'd like to see added to srvx for support reasons, is a 2 level = helper system. Level 1 would restrict them to #support, meaning, they = cant use their god mode unless they are in there. Level 2, would be as = it is now, they can use their god mode anywhere, we'd label these as = level 1 =3D Support helper, and level 2 =3D Network Helper.=20 If you need the reasoning behind that, ask me. Another thing id like personally, is a way to get a hold of logs on = demand, esp override. Like !sendlogs. It would allow me to follow up on = abuse complaints far faster than trying to retrieve a net admin to get = the logs for me.=20 I'll keep you guys posted on any new ideas that arise, but those are = the most solid, and agreed upon ideas as of right now. ---- Kaz (Ka...@Ga...) GamesNET Support Admin Http://www.GamesNET.net |
|
From: Mike K. <ka...@gl...> - 2002-01-23 01:33:52
|
What we'd like to see added to srvx for support reasons, is a 2 level = helper system. Level 1 would restrict them to #support, meaning, they = cant use their god mode unless they are in there. Level 2, would be as = it is now, they can use their god mode anywhere, we'd label these as = level 1 =3D Support helper, and level 2 =3D Network Helper.=20 If you need the reasoning behind that, ask me. Another thing id like personally, is a way to get a hold of logs on = demand, esp override. Like !sendlogs. It would allow me to follow up on = abuse complaints far faster than trying to retrieve a net admin to get = the logs for me.=20 I'll keep you guys posted on any new ideas that arise, but those are the = most solid, and agreed upon ideas as of right now. ---- Kaz (Ka...@Ga...) GamesNET Support Admin Http://www.GamesNET.net |
|
From: Entrope <en...@us...> - 2002-01-22 03:22:58
|
Alex <ru...@bl...> writes: > pike:~/srvx$ ./autogen.sh > aclocal: couldn't open `configure.in': No such file or directory > Usage: autoheader [-h] [--help] [-m dir] [--macrodir=dir] > [-l dir] [--localdir=dir] [--version] [template-file] > automake: couldn't open `configure.in': No such file or directory > Usage: autoconf [-h] [--help] [-m dir] [--macrodir=dir] > [-l dir] [--localdir=dir] [--version] [template-file] If configure.in is missing, you're probably using CVS HEAD (which we've more or less abandoned, and requires autoconf 2.5x). If you "cvs update -r rel-1_0" (or "-r rel-1_1-branch"), autogen.sh should work better. For srvx-2.0, we will be keeping configure.in and autoconf 2.13 compatibility, so this problem will go away. -- Entrope |
|
From: John M. <jo...@ic...> - 2002-01-22 03:05:23
|
Alex, I had this problem before when I was compiling it for AfterNET.. I can't recall how I got arround it tho.. It was when I was using Linux, it works perfectly on BSD. Ohh yeah! I remember now. Entrope (I think) ran it on his own system and sent the configure (and related files) to me. I'm assuming that's rel-1_0 from CVS you're trying to install there.. If so then I'd be happy to send you the files you need, is someone will tell me what they are. Regards, . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...... John McGarrigle e: jo...@ic... t: +44 (0)141 589 6657 i: 18220396 f: +44 (0)7031 151 215 w: http://www.johnmcgarrigle.com/ m: +44 (0)7944 604 644 ...... . . . . . . . . . . . . . . . . . . . . . . . . . . . . -----Original Message----- From: sta...@li... [mailto:sta...@li...] On Behalf Of Alex Sent: 22 January 2002 3:05 AM To: srv...@li... Subject: [Staff] [srvx-devel] compile problems pike:~/srvx$ ./autogen.sh aclocal: couldn't open `configure.in': No such file or directory Usage: autoheader [-h] [--help] [-m dir] [--macrodir=dir] [-l dir] [--localdir=dir] [--version] [template-file] automake: couldn't open `configure.in': No such file or directory Usage: autoconf [-h] [--help] [-m dir] [--macrodir=dir] [-l dir] [--localdir=dir] [--version] [template-file] Your install system is not very cross-platform :/ do i have to do this manually? Alex Schumann Assistant Coordinator \ ___ Residential Computer Network | | "You can no more win a war Oregon State University \._/ than you can win an earthquake." http://rcn.orst.edu | --Jeannette Rankin (1880-1973) _______________________________________________ srvx-devel mailing list srv...@li... https://lists.sourceforge.net/lists/listinfo/srvx-devel _______________________________________________ Staff mailing list St...@li... http://lists.noc.ic5.net/mailman/listinfo/staff |
|
From: Alex <ru...@bl...> - 2002-01-22 02:57:07
|
pike:~/srvx$ ./autogen.sh
aclocal: couldn't open `configure.in': No such file or directory
Usage: autoheader [-h] [--help] [-m dir] [--macrodir=dir]
[-l dir] [--localdir=dir] [--version] [template-file]
automake: couldn't open `configure.in': No such file or directory
Usage: autoconf [-h] [--help] [-m dir] [--macrodir=dir]
[-l dir] [--localdir=dir] [--version] [template-file]
Your install system is not very cross-platform :/ do i have to do this
manually?
Alex Schumann
Assistant Coordinator \ ___
Residential Computer Network | | "You can no more win a war
Oregon State University \._/ than you can win an earthquake."
http://rcn.orst.edu | --Jeannette Rankin (1880-1973)
|
|
From: R. B. S. <de...@vt...> - 2002-01-22 02:34:01
|
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 |
|
From: John M. <jo...@ic...> - 2002-01-22 02:02:44
|
Hey, would someone mind forwarding us a copy of the original email, to st...@li... Regards, . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...... John McGarrigle e: jo...@ic... t: +44 (0)141 589 6657 i: 18220396 f: +44 (0)7031 151 215 w: http://www.johnmcgarrigle.com/ m: +44 (0)7944 604 644 ...... . . . . . . . . . . . . . . . . . . . . . . . . . . . . -----Original Message----- From: sta...@li... [mailto:sta...@li...] On Behalf Of Entrope Sent: 22 January 2002 2:01 AM To: srvx-devel Subject: [Staff] Re: [srvx-devel] srvx 2.0 goals 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 _______________________________________________ srvx-devel mailing list srv...@li... https://lists.sourceforge.net/lists/listinfo/srvx-devel _______________________________________________ Staff mailing list St...@li... http://lists.noc.ic5.net/mailman/listinfo/staff |
|
From: Entrope <en...@us...> - 2002-01-22 01:59:55
|
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
|
|
From: Zoot <zo...@pl...> - 2002-01-22 00:17:22
|
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 |
|
From: R. B. S. <de...@vt...> - 2002-01-11 02:12:35
|
I'm not familiar with BDB or the alternatives.. I suppose I'll have to read up a little bit on them before I can contribute to this debate any more. As for alternatives.. my only suggestion right now is magic midgets that can fly and are good at relay races : / -def > There are definite advantages to human readable, text based databases; > but at the same time, it seems the goal for the srvx rewrite is to > assure scalability to tens of thousands of users. It's debatable whether > switching databases will be necessary at all -- do Dalnet, Undernet, or > Quakenet have services that require souped up databases? It may be that > we're trying to fix something that isn't broken. Of course, the fact > that the big three networks with services are using derivatives of IRC > Services or a similar home-brewed solution complete with primitive > binary database doesn't mean their approach will work for us. Perhaps > talking to some Dalnet or other big network administrators will prove > informative. > > The most compelling reason to switch databases as GamesNET grows may > turn out to be fault tolerance, not performance. We should consider > fault tolerance within one installation of srvx along with allowing for > multiple, redundant srvx setups. For example, if the server's power > cycles, srvx's database should be internally consistent and have > retained its data up to the moment the power went out. It should also be > possible for srvx to replicate its databases to slaves, which are ready > to take over as the primary services should they disappear. Storage will > be the most difficult part about allowing multiple redundant srvx > setups, and our choice of database will be important in making it > possible. It should be relatively easy for a backup set of services to > realize when they need to kick in and do so. > > If we choose an out of process relational database, it should not only > pass the ACID test, but allow replication. As far as I know, MySQL and > PostgreSQL have incomplete or experimental replication support. I assume > the oodb approach would lend itself to database journalling and > replication fairly easily with the dirty flags, though we would need to > implement it ourselves; replication would just involve sending out > journal entries as they are written to the slaves. Fault tolerance at > just one level could suffice, though implementing one would be a step > towards completing the other. > > Issues with allowing other processes to directly access the data > concurrently along with srvx are, as Entrope pointed out, locking and > other synchronization issues, and enforcing rules to keep data > consistent. This will likely not only requires isolated transactions, > but the duplication of srvx's logic. For example, rules governing which > characters a handle may or may not contain would be written in srvx, > then written again for the web interface, etc. Updating this logic would > be a nightmare. It would probably be best to enforce a familiar tiered > database design; e.g. web interfaces and other external processes > needing access go through srvx, which talks to the database. This design > allows srvx to enforce rules to maintain the integrity of the database, > and like Entrope said, makes having an out of process database mostly > pointless. We must enforce the separation of storage and "business > logic." > > Looking for obvious candidates to cull, I believe we should eliminate > (4), since it offers us only the advantages of offloading storage and > comes with the double whammy disadvantages of having to implement > locking and IPC. Choice (2) seems to lack any advantages whatsoever, so > that's right out too. (3) and (6) seem to violate tiered design > principles. > > This leaves us with the choice of multiple saxdbs plus IPC, oodb on > Berkeley DB plus IPC, and oodb on proprietary DB plus IPC. saxdb would > require an overhaul to make fault tolerant, but that isn't yet a > requirement; most likely saxdb is out. If this is the short list, I hope > we've overlooked a marvellous approach, because I'm not sure that I like > the choices. > > # Zoot > > > _______________________________________________ > srvx-devel mailing list > srv...@li... > https://lists.sourceforge.net/lists/listinfo/srvx-devel |
|
From: Zoot <zo...@pl...> - 2002-01-10 21:53:49
|
There are definite advantages to human readable, text based databases; but at the same time, it seems the goal for the srvx rewrite is to assure scalability to tens of thousands of users. It's debatable whether switching databases will be necessary at all -- do Dalnet, Undernet, or Quakenet have services that require souped up databases? It may be that we're trying to fix something that isn't broken. Of course, the fact that the big three networks with services are using derivatives of IRC Services or a similar home-brewed solution complete with primitive binary database doesn't mean their approach will work for us. Perhaps talking to some Dalnet or other big network administrators will prove informative. The most compelling reason to switch databases as GamesNET grows may turn out to be fault tolerance, not performance. We should consider fault tolerance within one installation of srvx along with allowing for multiple, redundant srvx setups. For example, if the server's power cycles, srvx's database should be internally consistent and have retained its data up to the moment the power went out. It should also be possible for srvx to replicate its databases to slaves, which are ready to take over as the primary services should they disappear. Storage will be the most difficult part about allowing multiple redundant srvx setups, and our choice of database will be important in making it possible. It should be relatively easy for a backup set of services to realize when they need to kick in and do so. If we choose an out of process relational database, it should not only pass the ACID test, but allow replication. As far as I know, MySQL and PostgreSQL have incomplete or experimental replication support. I assume the oodb approach would lend itself to database journalling and replication fairly easily with the dirty flags, though we would need to implement it ourselves; replication would just involve sending out journal entries as they are written to the slaves. Fault tolerance at just one level could suffice, though implementing one would be a step towards completing the other. Issues with allowing other processes to directly access the data concurrently along with srvx are, as Entrope pointed out, locking and other synchronization issues, and enforcing rules to keep data consistent. This will likely not only requires isolated transactions, but the duplication of srvx's logic. For example, rules governing which characters a handle may or may not contain would be written in srvx, then written again for the web interface, etc. Updating this logic would be a nightmare. It would probably be best to enforce a familiar tiered database design; e.g. web interfaces and other external processes needing access go through srvx, which talks to the database. This design allows srvx to enforce rules to maintain the integrity of the database, and like Entrope said, makes having an out of process database mostly pointless. We must enforce the separation of storage and "business logic." Looking for obvious candidates to cull, I believe we should eliminate (4), since it offers us only the advantages of offloading storage and comes with the double whammy disadvantages of having to implement locking and IPC. Choice (2) seems to lack any advantages whatsoever, so that's right out too. (3) and (6) seem to violate tiered design principles. This leaves us with the choice of multiple saxdbs plus IPC, oodb on Berkeley DB plus IPC, and oodb on proprietary DB plus IPC. saxdb would require an overhaul to make fault tolerant, but that isn't yet a requirement; most likely saxdb is out. If this is the short list, I hope we've overlooked a marvellous approach, because I'm not sure that I like the choices. # Zoot |
