Anope IRC Services
Anope Development => Feature Requests => Topic started by: Kevin M on November 23, 2009, 04:43:38 AM
-
I'm not sure if this has been suggested before or not, but I think it'd be amazing for Anope to have some sort of API. Primarily so that you can use it to manipulate services without actually being connected to IRC. I know I'd use it. 8)
-
would be nice to separate the code a bit
1. library of none irc functions
2. library of database
There is a lot of code work that could be done, doubt it will happen
-
Do you mean it'd be wise to more or less rewrite anope? :P
-
Personally I would very much like to see a feature that would allow 3rd parties to communicate with anope without the need of going through a relatively slow MySQL server or so.. whether something like that will be done is another matter..
As for rewriting anope, that s what the development branch, 1.9, is about. While not a rewrite per se, it ports anope to C++ and as such parts of anope are progressively being rewritten, though not from scratch.
There have been modules for 1.8 that allow anope to take commands through SQL, from direct connections, but I don't think one was ever completed and considered "stable".
For 1.9, it aims to support a live MySQL DB backend reducing the need for an API like interface.. Doesn't make it less interesting, just less likely to be done in the foreseeable future..
-
What would this Live MySQL DB do? As apposed to the current (1.8 ) MySQL solution. :P
-
It would be updated in realtime, and Anope would read changes made to it and apply them to the running services.
-
Nice. :D I've had a chance to look at 1.9's new config and well, it's some snazzy stuff right there. :D
-
Discussing "Live" SQL is interesting because for all intents and purposes current incantations in both 1.8 and 1.9 (Live SQL attempts) are slow, and lumpy.
What I had considered discussing and this really needs some intelligent and interested people to thrash out would be whether we can retain the flat file structure, a memory storage system and MySQL where 'relevance' is the key, and whether SQL queries can be answered via some kind of intermediary system (ala xmlrpc) whilst still providing near on seamless MySQL application style stuff.
A theory we had considered was having an updates table in SQL which stored 'changes' between flat file and/or memory and the 'main' SQL DB which could be used to answer 'regularly' changing queries without having to enumerate or dig through a full database.
There's so many other options available it's a question of intelligent people (far more intelligent than me!) getting stuck in with ideas, theories and some good old fashioned kicking.