Reformatted excerpts from Mark Alexander's message of 2009-04-28: > Maildir filenames are unique, but they would need to be ordered by > time, since sup depends on that ordering (look in maildir.rb for where > it uses sort). I'm not sure if mail delivery programs (I use > procmail) guarantee that the filenames are ordered that way.
That's correct; the name is not sufficient as ids because Sup needs a single pointer into the Maildir as a marker for what it has already processed, so we have to use something ordinal. But it can't just be any old ordinal, it has to be something that corresponds with the way messages are written to the Maildir, in order to be able to divide newer messages from older ones. A timestamp is the obvious choice, but messages can have the same timestamp, so then what do you do? The current approach is to sort by another arbitrary field (in this cae, message size), which gives a unique ordering, but doesn't match up (All this rigamarole about ordinals and blah blah blah is necessary because I don't want Sup to rescan the entire Maildir unless absolutely necessary. One day I'll convert my mbox to a Maildir with 250k files in it, and a rescan will kill me, especially at Ruby speed.) > I will say that the patch I sent out for maildir.rb has made my life a > lot happier, but it's still not ideal because of the race condition I > mentioned. > > William was talking about using some other scheme to generate IDs. We > should see what he has to say about this. Well I haven't quite started on it yet, but my plan is to: a) Sort files by timestamp, and then by something else (maybe name), and use the position in that array instead of the timestamp. This doesn't solve anything, but it will make the ids prettier, and removes the hideous "%7d" thing. b) When polling, if the current "offset" is N, return all messages that have a timestamp >= the Nth message. So this will mean that we'll rescan messages on occasion, but we shouldn't miss any. Any obvious flaws? -- William <wmorgan-...@masanjin.net> _______________________________________________ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk
