[IRCServices Coding] New IRC Services project

[Ballsy]

	In the manner you describe it, I don't know of a single database 
that could support a large network in that way.  But if a mySQL back-end 
were to be implemented, I imagine it would involve services querying the 
database when a user identifies for a nick, for example.  Services would 
load all pertinent database info about "nick" as it could, and store it 
until the user leaves (maintaining a sort of internal 'volatile' database, 
as it does now).  Services could do the same for when a channel is 
created.  The 
first user joins, Services query mySQL for all info (ie. ACLs, topic, etc) 
and store it until the channel is emptied.
	I don't know how real-time it is, or if it's changed in the last 
couple years, but I believe DALnet (if you want a LARGE network situation) 
uses/used a shared DB scenario in that the services DBs are used for their 
users.dal.net website as well.  It's possible though, that there is a time 
delay and the data is just copied over...I dunno.
	I imagine that there is a secure, scalable, dependable 
way to do this sort of thing, but I certainly don't purport to be a DB 
expert.

David


Quoth Craig Edwards on Dec 19 at 18:21,

> MySQL databases arent really a good idea for an ircservices server on a large network - imagine the number of constant queries involved, it would be a much busier situation than many large websites, you would have to make a query for practically every RAW irc line from your uplink, e.g. for checking access, etc. If not for every RAW line, but for every MODE, JOIN, and PRIVMSG to a pseudoclient, and every connect, NICK, etc... Not to mention that MySQL's transaction support isnt that good (MySQL's one and only downfall) which would mean maybe a database such as PostgreSQL may work much better in this case. I have my doubts about performance though. Would connections to the database be persistent? Im not sure about the low level workings of DBMS systems but for this kind of application the connection would not need to be closed after each query, the slowdowns would be unbelievably slow.
> 
> >On Wed, Dec 18, 2002 at 09:38:58PM +0000, Craig McLure <Craig at chatspike.net> wrote:
> >> Just a note.. do you realise how dangerous MySQL databases are? a while back i was discussing with my staff the subject of making one, Can you garuntee that MySQL wont crash? can you be totally certain that no-one else can access your database and make significant changes? currently the "FlatFiles" are a much safer way to store information, and even if someone tries to modify them, its never easy.
> >
> >yes, and see how many important websites rely on mysql. MySQL 3.23 _is_
> >stable.
> >the goal is to allow others to access the database through websites, etc
> >... and modify it. And yes, MySQL can be configured to restrict access to
> >some people, with brand new techniques like login and password.
> >
> >I'm not sure mysql would be a solution though. postgres, with a set of
> >stored procedures for external modification of the database, would
> >probably be a better choice.
> >
> >> And still, as always, i dont see the point in BotServ.
> >
> >yeah, you don't, but some people do.
> >
> >lucas
> >------------------------------------------------------------------
> >To unsubscribe or change your subscription options, visit:
> >http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
> 
> 
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
>