GNOME Bugzilla – Bug 322669
Move IM log parsing into individual filters
Last modified: 2007-06-05 15:35:12 UTC
The current ImLog code does a lot of processing of dates and things like that, which are irrelevant for log indexing. We can make ImLog be an ImLogViewer-specific thing, and replace the ImLog filter with simplistic filters for each log type.
Created attachment 55327 [details] [review] Integration patch
Created attachment 55328 [details] FilterGaimLog.cs
Created attachment 55329 [details] FilterKopeteLog.cs untested
This seems to be the current ImLog code, should this be marked Resolved?
Nops ... current ImLog code has a single filter FilterImLog which uses separate Util-classes to handle Kopete and Gaim logs. Daniel was proposing (IMO) a cleaner design with separate Filters altogether to handle the different parsing methods - this will make it cleaner for filters. Since ImLogviewer needs to parse the logs again, this will cause some duplication of code. But it looks like Imlogviewer requires different style of parsing than Filters, in which case the code for them should be separated. dsd mentioned about this in mailing list recently. I guess someone just needs to polish it according to current CVS, give it some test and it should be OK.
The patch proposes moving ImLog.cs into ImLogViewer rather than sharing it between filters. Then the filters reimplement the text extraction, so yes there is a little bit of duplicated code. But the advantage is big: right now the ImLog-based filters are wasting lots of time parsing dates and things like that, then that information is being discarded. This was actually Jon's idea so all credit goes to him ;)
Created attachment 70809 [details] [review] Move Gaim and Kopete Log Filteres Into separate filters Hey, just working on updating. They have been working with the exception of enddate parsing, I can't tell, take a look at it and see what you guys think. I can't say I have a lot more I can do, so I'd kinda like to hand this off to someone, but I'll do whatever is needed :).
Fixed in r3769. DBera: The KonversationQueryable is quite specfic, is it also possible and feasible to move its log parsing into a filter?