another tech discussion - 21/01/03 09:19 AM
DISTRIBUTED SERVICES
or each servers plays the role of services
all the info is spreaded across servers
pros:
1) services are always online
2) there's no centralized power that controls them (in fact this is the main issue, since on most small networks supporting services, the one who has shell access is the big boss, and that leads to many problems. I've never heard of "abusing services power" problems on major networks, but I don't hang on them much)
3) services and ircd become more and more related (I mean on networks that support services of course;b) so uniting them ain't that senceless as it seems at first sight
4) even if the server is splited, everything goes on as usual - you can identify for your nickanme, use chanserv access, or send memos
There can be many problems tho. Like the sync. Each server has to keep it's own database and propagate all changes between servers. All the info should require timestamp, so the oldest timestamp tules over all others. Servers can propagate only changes to their database, every hub saves the timestamp of last split, so the splited server needs only the changes after that timestamp. Use of services may be disabled on splited servers.
In this concept there's no place for Operserv, since it's the major abuse source
Many of it features are realized already as server features, like jupe <-> resv {}, glines, others may be easily done, and many many more are not needed or can be used to abuse
Any opinions?
or each servers plays the role of services
all the info is spreaded across servers
pros:
1) services are always online
2) there's no centralized power that controls them (in fact this is the main issue, since on most small networks supporting services, the one who has shell access is the big boss, and that leads to many problems. I've never heard of "abusing services power" problems on major networks, but I don't hang on them much)
3) services and ircd become more and more related (I mean on networks that support services of course;b) so uniting them ain't that senceless as it seems at first sight
4) even if the server is splited, everything goes on as usual - you can identify for your nickanme, use chanserv access, or send memos
There can be many problems tho. Like the sync. Each server has to keep it's own database and propagate all changes between servers. All the info should require timestamp, so the oldest timestamp tules over all others. Servers can propagate only changes to their database, every hub saves the timestamp of last split, so the splited server needs only the changes after that timestamp. Use of services may be disabled on splited servers.
In this concept there's no place for Operserv, since it's the major abuse source
Many of it features are realized already as server features, like jupe <-> resv {}, glines, others may be easily done, and many many more are not needed or can be used to abuse
Any opinions?