This week I'm going to concentrate on:

• generalizing the event reporting system in Gaim. It'll consist of using an enum of supported events types, and a fallback to create events that are not specifically listed by Gaim.
• continuing writing the specification of course. I'm now following the XHTML2 working draft because it notes current issues and has elements/attributes/values tables.

On the side, I'd like to look into writing another set of gaim_log_common_writers that ensures a well-formed XML version of the log is outside of user space (it'll use Glib I

Many of the things carried over from last week.

• Fix the log viewer. I think it broke from having changed the format of the filenames, but it did crash on me once. This warrants investigation.
• Create an outline for the ULF specification.

need to

• Just an aside: look into util.c:gaim_markup_html_to_xhtml() and figure out how to merge adjacent style tags.
• Look into using Lucene4C, which is just the text-indexing engine of beagle ported to C. I don't think we can to assume that all of beagle is installed; perhaps Lucene4C will do roughly the same.

I've decided to outline my short-term goals for what I need to do. A friend asked me about it online, and I think it was a pretty clear breakdown of what I'm trying to achieve (code-wise). Before I begin, I'll describe it on a higher-level.

One of the overall goals is to allow multiple loggers to log in Gaim. Currently, Gaim keeps a single logger identifier selected, and uses a struct containing function pointers to corresponding logging activites - opening, writing, close, retriving. I will assume logging both conversations and system events (buddy sign ons, going aways, etc) are enabled. When a new logging entity is created (a conversation window opens), a GaimLog structure becomes associated with the entity until its destruction (the conversation window closes). Instead of having a single static reference to a logger for the whole duration of its life, I can either (1) let the association happen dynamically - when a logging activity is called, I'll check the prevailing setting, thus allowing users to change logging format mid-conversation - or (2) still have the reference be dynamic, but have it be a terminated linked list of these GaimLogLogger structures. Gaim would simply traverse these all these various functional pointers, and since they're all sane (e.g., if you try to write to a non-existent logfile, the file will be created), this is totally possible.