rethinking folders

Posted on January 15, 2016

Till now, flare has had a minimal notion of folders: a folder exists if there are any messages which have a folder tag that mentions it. The only other awareness of folders is that Waste and Spam are special-cased in the router. Messages in Waste are retired after 60 days (either after last access, if there was one, otherwise creation). Messages in Spam are retired after 30 days.

Oh, and the old spam code knew something of the Unsure folder, but that’s basically going away. I think what I’m going to do there, is if the gap is too small, it goes into General, and we have some chrome asking the user to train it. (Maybe.)

For bfilter training, we need a list of folders that comprise the “inbox”, corresponding to bfilter categories. These must still exist, even if they are empty, so that messages can be trained into them. Furthermore, it would be nice to generalize the auto-deletion code. I would like my Fedora and Haskell folders to auto-retire messages. And it’s struck me that it should be an option if auto-retirement happens to all messages, or only to messages that have been read. (Or to messages that have not been read?!?)

These are slightly orthogonal things, of course. I might care to auto-delete messages in my shopping folder after a year, say.

It’s just occurred to me that, for messages other than in Waste (or Spam), deleting should mean moving to Waste. (I don’t think we need an option to move to anything other than Waste. One can’t generalize everything!) Also, certain “immutable” folders must always exist (although ultimately we want to be able to change their names).

So, let’s try to pull this together. We need a list of folders. Each folder has some properties:

  1. name
  2. is it a bfilter category / member of “inbox”?
  3. immutable?
  4. do we auto delete? and if so…
  5. after how long?
  6. all messages, or only read messages?
  7. delete permanently, or by moving to Waste? (or by archiving?)

Some of the folders that I already use have these properties:

General  2 3
Spam     2 3 4 (30 days, all messages, permanently)
Waste      3 4 (60 days, all messages, permanently)
Haskell  2   4 (60 days, all messages, move to Waste)
shopping     4 (360 days, all messages, move to Waste)

How should we model this? Here’s the obvious way:

  name Text
  immutable Bool
  del Bool
  del_all Bool
  del_perm Bool
  del_days Int

I do wonder, though, if we drop the immutable flag, and instead have a magic number (special Int) that is 1 for the general folder, 2 for spam, 3 for waste, and 0 (or null) for anything else. Otherwise I don’t see how we can find the Waste folder if it’s called, say, Poubelle. Yes, I like this.

Now, how does this interact with tags? Do we simply say that the folder tag may take on a value that is in the folder list, and if it does, the magic applies?

I suspect that, no, we say the folder tag must have a value that is in the folder list, so “create and move” does actually create something. (And, of course, there will have to be a way to delete a folder.) In which case, surely the Tag should include a foreign key reference to the folder?

On further reflection, over a couple of days, I think that the right thing to do is to drop the idea that folders are anything to do with tags. Instead we create a new table which records the many-many relation between messages and folders:

  message MessageId
  folder FolderID
  UniqueFM message folder

That makes way more sense than anything else I was plotting. Now it’s just a small matter of implementation….