| Newsgroups |
gmane.mail.ifile.general |
| Message-ID |
<[email protected]> |
I've trained ifile on my entire backlog of mail; as a result, .idata
is nearly 840 meg. In my environment, .idata lives in NFS. The
result is that ifile startup takes 1-2 seconds. This hurts when I'm
receiving and classifying multiple messages at once. I wanted to
throw out a couple of random suggestions for
criticism/discussion/shootdown.
* Speeding up invocation:
One way of speeding up the invocation would be to have ifile run as a
daemon, and have command-line invocations just speak to the running
daemon.
If you didn't want to leave an ifile-daemon running all the time, you
could have it just run for 5-10 seconds after it was first invoked;
this would amortize the startup time over all of the messages in a
given batch.
Thoughts?
* Shrinking the file size:
Looking through idata, it seems that ifile parsed all of my uuencoded
PDF files and so forth just like they were normal text. As a result,
there are a whole lot of garbage-words that are meaningless,
e.g. 'zp'.
zp appears 7519 times in my email; 29 times it's in a Message-ID, the
other 7490 times its in uuencoded crap.
Two suggestions here:
- optionally parse mime headers, and only classify based on text,
html, and other meaningful content; this avoids parsing uuencoded
crap, PDF, jpegs, etc.
- give more flexibility in terms of which headers to omit from
parsing; e.g. I might like to omit message-ID and X-everything
headers while still parsing Received-by, etc. headers
Anyhow, let me know what y'all think.
Jeremy
PS With any luck, an alpha version of ifile-gnus.el will be released
sometime today.