Pages (3): 1 2 »
We've made a number of changes, but here's an update:
Cleanup: unreal.c has been cleaned up, with a lot of code moved to other functions from the main routine. It's now much easier to understand how it works, and much easier to extend in future.
Events: We now have an events system that we can use for any extension. unreal.c has been outfitted with a few of these, which are subject to change. We can add events of any name, but our convention is underscores instead of spaces, all lowercase. Comparing is case insensitive.
Speed: We've sped up a few sections that would've slowed down on larger networks. We're still working on this, but we can make many simple changes to speed up the processing in future.
File system: Applet has been working on a file system for Ezri, and has come up with a way of saving/restoring the database. Currently implemented as a developer module, we plan to integrate support for this into the services themselves.
Cleanup: unreal.c has been cleaned up, with a lot of code moved to other functions from the main routine. It's now much easier to understand how it works, and much easier to extend in future.
Events: We now have an events system that we can use for any extension. unreal.c has been outfitted with a few of these, which are subject to change. We can add events of any name, but our convention is underscores instead of spaces, all lowercase. Comparing is case insensitive.
Speed: We've sped up a few sections that would've slowed down on larger networks. We're still working on this, but we can make many simple changes to speed up the processing in future.
File system: Applet has been working on a file system for Ezri, and has come up with a way of saving/restoring the database. Currently implemented as a developer module, we plan to integrate support for this into the services themselves.
Lulolwen is a nerd
YAY!
"I must believe in something. I must believe that the world can be better. Better than this." -Looking For Group (www.lfgcomic.com)
Life is random. Learn to love living it.
sXe. (http://en.wikipedia.org/wiki/Straight_edge)
Life is random. Learn to love living it.
sXe. (http://en.wikipedia.org/wiki/Straight_edge)
Yay, indeed. :)
It's been a little while, so I thought I'd give an update on what we've been doing this week.
applet says he's planning on writing a configuration parser, that'll be interesting. I haven't seen anything yet, but we haven't come up with a final format yet either.
There's a new timer system to complement the events. The way in which they work is simple, and very similar to our event system. You register the timer to happen in N seconds, and provide it with any extra data that you need. In N seconds, that timer will be run. You can specify within the timer whether it should re-occur, be deleted, or no action (If you choose to extend the timer some other way, such as editing the struct. Not recommended, but it's there)
To prove to ourselves that we have a working implementation of both of these, we've written a basic NickServ ghost command. I'm happy to report that I've been killing myself all night.
Fixed a stupid bug that should've been caught long ago with the nickname change function, a couple of small oddities, slightly improved our compatibility with the UnrealIRCd server protocol, and of course we plan to add more.
Next update will obviously come next time we do something worthy of a mention. A day, maybe two, maybe another week. Not long, though. Unlike some projects, people actually work on this.
It's been a little while, so I thought I'd give an update on what we've been doing this week.
applet says he's planning on writing a configuration parser, that'll be interesting. I haven't seen anything yet, but we haven't come up with a final format yet either.
There's a new timer system to complement the events. The way in which they work is simple, and very similar to our event system. You register the timer to happen in N seconds, and provide it with any extra data that you need. In N seconds, that timer will be run. You can specify within the timer whether it should re-occur, be deleted, or no action (If you choose to extend the timer some other way, such as editing the struct. Not recommended, but it's there)
To prove to ourselves that we have a working implementation of both of these, we've written a basic NickServ ghost command. I'm happy to report that I've been killing myself all night.
Fixed a stupid bug that should've been caught long ago with the nickname change function, a couple of small oddities, slightly improved our compatibility with the UnrealIRCd server protocol, and of course we plan to add more.
Next update will obviously come next time we do something worthy of a mention. A day, maybe two, maybe another week. Not long, though. Unlike some projects, people actually work on this.
Lulolwen is a nerd
Makes a change O_o
What in the devil is a snippet.
err.. oh shit what did I do.
Snippety Snippety Snippety Snip
err.. oh shit what did I do.
Snippety Snippety Snippety Snip
Time for another quick update before I get back to work.
The main effort recently has been IRCd compatibility. I've been going through the unreal.c code and adding support for many of the advanced protocol options that Unreal supports. It's definitely starting to take shape, with support for tokens such as NICKv2 and TOKEN. There were also a couple of memory leaks that could have easily been prevented, so those are now fixed. Though NOQUIT is sent, it is not technically supported as yet due to the lack of a second server on the testing grounds. No doubt more bugs will come up then. In the meantime, there'll be support for SJOIN, NS etc by the time the next update comes.
For those who don't speak fluent server-to-server protocol, this means that considerably less bandwidth is used when synching the services with the server(s) on an IRC network. With "TOKEN" for example, words like "MODE" become simply "G" when sent across the servers, this doesn't sound like a big gain, but if you have 1000 users and 500 channels, you would save 4.5kb on the MODE command alone (Other tokens reduce this much further) and this quickly adds up. Ziplinks might be supported, but this is doubtful, and certainly not on the immediate feature list. Ezri makes sure, of course, that it only makes use of what the other server supports, although most servers will support all of these tokens, and you'd very likely know if they didn't. ;)
Apart from the technical updates on the IRCd side, there hasn't been much work implementing commands, much of the work has been under the hood, fighting with bugs as they come up, adding support for all the extra information that's coming out of the IRCd when we request it, and brainstorming ideas for how to implement other parts of the services.
Stay tuned, I guess.:)
The main effort recently has been IRCd compatibility. I've been going through the unreal.c code and adding support for many of the advanced protocol options that Unreal supports. It's definitely starting to take shape, with support for tokens such as NICKv2 and TOKEN. There were also a couple of memory leaks that could have easily been prevented, so those are now fixed. Though NOQUIT is sent, it is not technically supported as yet due to the lack of a second server on the testing grounds. No doubt more bugs will come up then. In the meantime, there'll be support for SJOIN, NS etc by the time the next update comes.
For those who don't speak fluent server-to-server protocol, this means that considerably less bandwidth is used when synching the services with the server(s) on an IRC network. With "TOKEN" for example, words like "MODE" become simply "G" when sent across the servers, this doesn't sound like a big gain, but if you have 1000 users and 500 channels, you would save 4.5kb on the MODE command alone (Other tokens reduce this much further) and this quickly adds up. Ziplinks might be supported, but this is doubtful, and certainly not on the immediate feature list. Ezri makes sure, of course, that it only makes use of what the other server supports, although most servers will support all of these tokens, and you'd very likely know if they didn't. ;)
Apart from the technical updates on the IRCd side, there hasn't been much work implementing commands, much of the work has been under the hood, fighting with bugs as they come up, adding support for all the extra information that's coming out of the IRCd when we request it, and brainstorming ideas for how to implement other parts of the services.
Stay tuned, I guess.
Lulolwen is a nerd
It's been a while since the last update, so I guess now is as good a time as any to explain what we've been doing for the past month.
Again, very few of the changes recently have been user-end features as we continue to improve the core. This time, there was one main focus: "Improve spaghetti code". In doing so, we added a few conveniences for developers, and a few more possibilities for extension writers.
There's a reason that I say "Improve spaghetti code" rather than "Remove spaghetti code", and that's mainly because the result is almost always moving that spaghetti code to somewhere else. Far be it from me to break my own rule, and as such I've moved up to a quarter of the spaghetti code into nickserv.c, which actually handles all of the services clients at the moment (NickServ, ChanServ, OperServ).
The result of moving the spaghetti code is that we now have a "message struct" rather than just passing pieces of it. It contains the real target (A nickname or channel), the "implied" target (More on that in a second), and other such information. Previously, it was impossible to tell if the target was real or implied, and adding more unuused parameters to the command function was impractical. The struct is our solution to that.
So what's an implied target? Implied targets are the channels specified by a command, either by sending it as "#channel command", or "command #channel", Ezri is now able to interpret both and add them to the struct, so developers shouldn't have to worry about this. There are, of course, a series of functions to get the relevant data from the message struct, and a "seek" function to move the internal message pointer along.
Another minor convenience is the loss of the _extension functions. These were previously necessary due to memory allocation. With a little wizardry that I can only hope is cross-platform compatible, the same functions will now work across both the core and the modules section.
For those wanting updates on end-user/end-ircop features, you'll need to hold on a little longer. Since nobody is currently using Ezri in a production envrionment, that isn't a problem. We still have plenty of work to do before we release a true beta, including the following features:
- Database support, modular file systems.
- Configuration file parser
- Memo capability, stats capability
- Unload/reload command
- Threading?
You'll be kept up to date.
Again, very few of the changes recently have been user-end features as we continue to improve the core. This time, there was one main focus: "Improve spaghetti code". In doing so, we added a few conveniences for developers, and a few more possibilities for extension writers.
There's a reason that I say "Improve spaghetti code" rather than "Remove spaghetti code", and that's mainly because the result is almost always moving that spaghetti code to somewhere else. Far be it from me to break my own rule, and as such I've moved up to a quarter of the spaghetti code into nickserv.c, which actually handles all of the services clients at the moment (NickServ, ChanServ, OperServ).
The result of moving the spaghetti code is that we now have a "message struct" rather than just passing pieces of it. It contains the real target (A nickname or channel), the "implied" target (More on that in a second), and other such information. Previously, it was impossible to tell if the target was real or implied, and adding more unuused parameters to the command function was impractical. The struct is our solution to that.
So what's an implied target? Implied targets are the channels specified by a command, either by sending it as "#channel command", or "command #channel", Ezri is now able to interpret both and add them to the struct, so developers shouldn't have to worry about this. There are, of course, a series of functions to get the relevant data from the message struct, and a "seek" function to move the internal message pointer along.
Another minor convenience is the loss of the _extension functions. These were previously necessary due to memory allocation. With a little wizardry that I can only hope is cross-platform compatible, the same functions will now work across both the core and the modules section.
For those wanting updates on end-user/end-ircop features, you'll need to hold on a little longer. Since nobody is currently using Ezri in a production envrionment, that isn't a problem. We still have plenty of work to do before we release a true beta, including the following features:
- Database support, modular file systems.
- Configuration file parser
- Memo capability, stats capability
- Unload/reload command
- Threading?
You'll be kept up to date.
Lulolwen is a nerd
And it's update time again.
Some of the stupid things have been fixed, which is always nice. strncpy_safe wasn't being as safe as it should be, some bugs have been squashed regarding the handling of user modes in the Unreal module (Which is currently the only IRCd module), and some additional support for IRCd features has been added - And this time, put into practical use.
First off, though - New in the core. In the past couple of days we've written two very useful functions for use later. One will interpret a "time string" when entered (For example, 1h30m representing 1 hour, 30 minutes), and the other will determine whether a string matches a ban mask. Both of these will naturally allow more complicated modules than before, which can only be a good thing.
Internally, we've also updated the core to understand vHosts, vIdents, and changes to the "real name". We've even come up with a very quick oper-assigned vHost command. It works, not as well as it will eventually, but it works. This might be the first update in a long time that's come with a new feature, but the fact that could be set up within a few minutes is a testament to how much easier we've made it to make an Ezri module.
During the time since we started work on Ezri, we've changed a number of things in the core - Either through a change of mind, or making use of things that weren't there before, etc. This caused a lot of code to be in the wrong place, or simply redundant. Rather than leave it there to cause problems later, we've gotten rid of a lot of the stray definitions and headers that were loaded without cause. The net result is a smaller compiled file size (Woo), and a faster compilation time.
Finally, due to the changes that've been made, I'm referring to things from now on as "0.5". This version number isn't currently used or defined anywhere within the project, however, and is purely a marker for me. I just thought someone may find that interesting.
Some of the stupid things have been fixed, which is always nice. strncpy_safe wasn't being as safe as it should be, some bugs have been squashed regarding the handling of user modes in the Unreal module (Which is currently the only IRCd module), and some additional support for IRCd features has been added - And this time, put into practical use.
First off, though - New in the core. In the past couple of days we've written two very useful functions for use later. One will interpret a "time string" when entered (For example, 1h30m representing 1 hour, 30 minutes), and the other will determine whether a string matches a ban mask. Both of these will naturally allow more complicated modules than before, which can only be a good thing.
Internally, we've also updated the core to understand vHosts, vIdents, and changes to the "real name". We've even come up with a very quick oper-assigned vHost command. It works, not as well as it will eventually, but it works. This might be the first update in a long time that's come with a new feature, but the fact that could be set up within a few minutes is a testament to how much easier we've made it to make an Ezri module.
During the time since we started work on Ezri, we've changed a number of things in the core - Either through a change of mind, or making use of things that weren't there before, etc. This caused a lot of code to be in the wrong place, or simply redundant. Rather than leave it there to cause problems later, we've gotten rid of a lot of the stray definitions and headers that were loaded without cause. The net result is a smaller compiled file size (Woo), and a faster compilation time.
Finally, due to the changes that've been made, I'm referring to things from now on as "0.5". This version number isn't currently used or defined anywhere within the project, however, and is purely a marker for me. I just thought someone may find that interesting.
Lulolwen is a nerd
Sometime in mid October, I started working on a set of IRC services to replace Anope, despite being a mammoth task in itself, we seem to be well on our way come mid January, and I've decided to make our progress available to anyone who wants to read up on it.
If anyone's interested in the current source of Ezri Services, message myself or applet for a copy, we can easily be found in #c or #welcome.
Port: Win32 only, would be relatively trivial to port and has been written with this in mind. Very little would need to be done, the sleep function differs slightly in *NIX, the socket library is similar, and a macro for strncpy would need to be added. Other than that, nothing much to be done.
As far as IRCds go, we've only written a module for our own UnrealIRCd 3.2.7, which is a stock version with pretty normal compilation settings. There's no tokens support, no SSL or ziplinks (These probably won't be added for some time, if at all, as many services-IRCd links tend to go across the local machine). We've currently gotten it to understand PART, JOIN, QUIT, NICK (join/change), EOS (It doesn't yet send EOS, but that's minor), PRIVMSG + CTCPs (External handling routine), TOPIC, MODE, and a few other minor commands, so IRCd support is probably one of the most complete things we have.
Clients: We currently have a limited NickServ, ChanServ and OperServ. We haven't written many commands, as we've been busy on the core. We've recently enabled things to actually be removed from lists (About time), but most of the basic commands such as INFO, REGISTER, LOAD etc are working. Access lists work, and can be added to. Editing/deleting hasn't been added yet, but we're working on more core features at the moment.
Release: We're not yet ready to release anything, but we're at the stage where we can actually talk about it as if it means something. Though this is "my" project, applet has also volunteered a lot of his time to work on the file system, amongst other things, and unfortunately has done more than enough to earn himself the position of "developer" ;)
Look out for a true beta later in the year, at the rate things are going. We've a lot of work to do, but we're well on our way.