This is broadly broken down into 4 areas: cleanups, protocols, logging, and other.
- Autoconf support – This would be nice. Means it could check for the presence of MySQL and build the plugin if it finds support for it. Also would give IMSpector more “acceptance”. Autoconf looks a bastard though.
- Security audit – Would be great to have someone look over the code and find the potential buffer problems and the like.
- Custom string class – Right now IMSpector uses std::string and also the odd character array, because string lacks things, especially formatted printing. There are a few alternative string classes to look at; I’m sure one would be suitable. Or I could take the DIY approach.
- Better socket getline – Currently the implementation for reading upto a \n from a socket sucks, to put it simply. Need a buffering read-a-line code.
- Chroot support – This would be a very nice feature and go a long way to mitigating any security issues with IMSpector.
- Fork-pool model – This would speed things up abit on very busy systems with loads of clients.
- MySpaceIM – Looks doable, but the server runs on many ports so this could be difficult for IMSpector to capture.
- AIM 6 – Simular to MSIM in that it is port abuse, it hijacks port 443.
- MSN file transfers – The offical client seems to send files in a different way which IMSpector currently misses. Needs investigation.
- Other DB systems – Oracle etc.
- Configurable file logging using formatted printing.
This is a collection of fairly random ideas, some of which are fairly trivial to implement, some are much harder.
- AV scanning – Would be very involved, but theoreticaly possible to hold files as they are transfered and only send the file onto the client if it passes AV scanning.
- Regex-based text replacement – This could have many uses, from censoring peoples chats to stopping exploit attempts. While the current system of content replacement works, it could be better!
- Make the socket-API support TCP connections for offloading the censoring service onto another box, and support blocking/filtering of events other then messages.
- The ability to not log certain local (or remote?) IDs.
- A log-viewer that can view MySQL/etc database logs.