Use entry tags for read, important

[lemon24]

Use entry tags for read, important; it may make things simpler.

Pending #228.

Unsolved problem: How does storage know to cache .reader.read? (the tag name can change based on Reader.reserved_name_scheme)

[lemon24]

OK, thought about this a bit.

Invariants

These things shouldn't change:

• The public get_entries(read=...), since it's user-friendly.
• read and important should continue to be optimized (compared to tags).

Tag names

The fact that the corresponding tag names can change is an issue. Storage (and Search) must be told out-of-band that "this tag actually means read, use whatever optimization you have".

Also, because the tag prefix must be configurable, the read part must be too.

Possible solutions:

1. Get rid of the Storage.markas... APIs. Reader wraps read tags in a special class, e.g. SpecialTag('.reader.read', TagHint.READ).
   • This is good, because non-optimized storages can ignore hints.
   • This is bad, because Reader must add hints when needed, otherwise those entries don't get the optimization.
   • Storage should store the hints even if it doesn't use them, in case it does want to implement them later.
   • Maybe we could use triggers to set the flag when the corresponding tag is added/removed.
2. Don't change anything in Storage. In Reader (maybe with a plugin), add/remove tags on markas...
   • Again, Reader cooperation is required for consistency.
   • Can be made transactional later by allowing Storage.markas... to add/remove tags; Reader would then say storage.mark_as_read_unread(True, '.reader.read').
     • The equivalent of Storage storing the hint is Storage keeping the tag.
   • For performance, Reader can intercept tags that mean read in EntryFilterOptions, and convert them into read= arguments (if possible).
3. Get rid of the Storage.markas... APIs. Keep Storage and Search updated with a mapping of special tags.
   • Again, Reader cooperation is required to set it properly.

Regardless of what we do, it seems pretty clear that none of these is actually making things simpler implementation-wise, and we're just moving the info about read etc. being special around.

Also, if both the flag and the tag are stored, changing one should always change the other. From this perspective, (1) is likely the best solution, since it models all the required data.

A light version of (2), where Reader (or a plugin) just sets tags for convenience seems like a decent approach if we just want to provide this to end users.

I initially started this whole thing thinking it would help solve #254 (by attaching an "added date" to each tag). But e.g. for read I'd like to store the date when it was last changed (read/unread); if we use a tag for it, unread means "no read tag", so we're left with no date (unless we change out model and use 2 tags...).

Conclusions

• (1) is the more correct solution, (2) is quick to do if we only care about end user convenience
• doing this alone won't help with #254
• it's debatable if even the best possible implementation of this makes things simpler than what we have now (2.1)
• this depends on #228 (entry tags), which may never be implemented; doing it only for this issue doesn't solve any problem

Closing this at least until #228 is implemented.