New approach to grouping/backend/marking - good or bad idea?

[Rob Browning <rlb@cs.utexas.edu>]

These may very well just be "bad ideas(TM)", but, after running them
by another Gnus notable and not getting "laughed out of the room", I'd
like to run them by whoever else will listen to see what they think.
Aside from possibly being just wrongheaded, these ideas might also be
completely unimplementable.  Since I don't have enough experience with
the Gnus codebase to evaluate if that's true easily, I figured I'd ask
those who do.

There are two bits here.  The bit that I feel pretty sure is a good
idea is that of adding "message keywords" to Gnus.  Imagine that you
can (either manually, or via automatic means like the split process),
add arbitrary keywords to articles.  These keywords could then be used
for whatever you like, but I could imeediately see a use for them in
searches, narrows, etc.  This would easily eliminate all the arguments
that keep me from being happy just using total-expire.

For example, I would like to use a "todo" keyword, and attach that to
articles that I need to do something about.  Then I could enter a
group and do a "/ k todo" or whatever, and see all those articles.

I could even see extending the system to support both user and system
level keywords (i.e. separate keyword namespaces).  The system level
keywords could be used to implement a more flexible "marking" system.
Things like read, expired, killed, could just become keywords.  This
would mean that you could easily support something like allowing an
article to have two marks, and, with a little more work, the user
could decide which of their kewords receive the "dormant behavior",
the "ticked behavior", etc.

I've also been toying with a the idea of a much more radical variation
on the same theme.  What if the mailer stored every message *only
once* in a guaranteed uniquely named file (across the entire backend),
and then used keywords (instead of physical placement in the
filesystem) to indicate groups?

In such a setup, a "group" could just become the set of articles which
matches a given keyword search criteria, crossposting an article would
just means adding more keywords to it, hardlinks wouldn't be needed
for efficiency, deciding when to delete an article would be (as it
should be) a completely orthogonal issue from deciding which groups it
is in, and, finally, since you have a guaranteed unique ID for every
article, you could easily use those article ID's like URLs to refer
back to important mail from other files.  You could safely say things
in your todo list like

  * Make sure to implement the frobbing mentioned in in <gnus://4126>
  * Don't forget the devices for the ritual <gnus://2311>

and then access these articles instantly via a nifty
gnus-jump-to-article function that worked from any emacs buffer.

There are also a couple of system level advantages to using this
approach.  One minor one is that you could use subdirectories
automagically for efficiency.  For example, you could store article
<gnus://23> as:

  Mail/storage/000/000/000/023

This way no directory would ever have more than 999 files.  As
compared to the current system where you can end up with thousands of
files in a single group, this would probably be a performance win,
though it's arguably one that would really be better solved at the OS
level.

Is this interesting?  Would it be too much work for too little gain?

Thanks

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930