Re: new backend?

[Ted Zlatanov <tzz@lifelogs.com>]

On Fri, 06 Dec 2002, jan@rychter.com wrote:
> Let's say I'd like to look at my mail differently -- I'd like to
> look at it as bundles of messages. A bundle would be several threads
> combined together, possibly from several groups.
[example snipped]

OK, so essentially you want to explicitly attach an article to a
thread.  Kai's example showed how to do it, I think.

Information such as the last activity date about a thread can be
deduced from the contents of the thread.  If you need more parameters
than can be deduced from the thread contents, you may need to use a
new group per "bundle" with the current Gnus, or somehow store the
thread meta-data in the group parameters.

> It's not really a replacement for mail groups, it's just another way
> of looking at your mail. Think for example "trouble ticketing
> systems". I've described a simple use above, but there are many
> others.
> 
> Does that explain it? If yes, what's the best way to go about
> implementing it?

I don't know the best way, but perhaps I can help you figure out if a
new backend is the answer.

Backends deal with article storage and retrieval.  I don't think you
want a new backend.  It's a lot of work, and may not be necessary.

Ideally, your functionality should work with any backend that allows
threading and group parameters.  I think you want to hook into the
thread generation code (gnus-sum.el is a good starting point, I
think).  Given a thread, perhaps you want to add your thread meta-data
to it, and make it visible through summary line formats.

I can imagine a thread about "ticket 985" the way you describe.  A
useful functionality for you, if I understand your needs, is to
move/copy an article from any group to the tickets_group:bundle_985
thread in one shot.  So perhaps the key thread meta-data you want is
a thread name, for article copy/move operations?  Then you can
associate almost any data with that thread name.

I hope that helps...

Ted