I came home from school today a little surprised to see my bandwidth clogged and my screenshots of the Gaim/Evolution integration/synchronization plugin up on gnomedesktop.org. It was pretty cool :) Now I just hope it gets accepted into Gaim CVS, but I'm still not betting on it.
Work is going well on this. It'll be awhile before it's anywhere near what the old libcomprex was, but it's getting there, and is far easier to maintain and use. It's now GObject-based, replacing my own limited object framework. However, it's still a pain to write this library, due to its complexity.
The new filesystem abstraction framework will help replace the really ugly algorithms needed to open archives inside archives. Even the local filesystem is represented by CxLocalFileSystem, a subclass of CxFileSystem. CxArchive is also a type of CxFileSystem. Each CxFileSystem contains a list of all file pointers belonging to files in the filesystem, and all CxFileSystems existing underneath the filesystem.
Under the old design, all file/archive access functions would go through one evil file of code in a horrid file named io_internal.c. Depending on how you call the internal function, and what is contained in the path, you could get a CxArchive or a CxFile. However, when destroying the object you receive, there is no way to delete every other object somehow associated with that one for sure, without all these reference issues and memory leaks and such.
Now, under the new design, you always have, at minimum, a pointer to the top-most CxFileSystem that you're working with. When you destroy this, it destroys all node references under it, closes all file pointers, and then destroys all CxFileSystems under it as well. That in turn destroys those things under that. The reference problem goes away, and it's pretty clean. A lot cleaner than the CxContext I was about to implement for the old design.
Once I have most of the base written, I'll migrate all the archives and replace the old file scheme loading stuff (ftp, http, etc. access methods) with CxFileSystem implementations.
Things will change of course from the old API to the new one. In the old one, you could access a README.txt nested deep within an archive in an archive in an archive with one command. In the new API, you'll need to grab an instance of the local file system and then access it with a pointer to that. Not much harder, and far cleaner.
Well, tomorrow (actually, in just over an hour) is my birthday. I'll be turning 20. I'm not actually doing anything tomorrow, since I did stuff last weekend, so it's going to be a bit of a boring, miserable day. I'll probably either avoid home, or work a lot. That sounds fun. Maybe I'll buy myself something.