Re: new backend?

Re: new backend?

[Ted Zlatanov]

On Thu, 05 Dec 2002, jan@rychter.com wrote:
> I would like to write some code that allows me to access messages in
> my nnml spool. I will need to combine multiple messages from
> multiple groups together and operate on them (set marks, move
> between groups, etc). I still want to use nnml for storing messages,
> but I'd like to be able to access them in two ways: via standard
> nnml groups and via my new interface.
> 
> What would be The Right Way to implement that kind of functionality?
> 
> I have identified some starting points:
> 
>   -- nnvirtual.el. Very complex code. I probably don't need most of
>      it.

I'm not sure what you're trying to do, but combining multiple groups
so they look like one group is *very* easy with nnvirtual.

Perhaps if you explained your goals better, you'd get more
information.  Why do you want combined groups and marks?

Ted

Re: new backend?

[Kai Großjohann]

Jan Rychter <jan@rychter.com> writes:

> But let's say I get another message from that person, related to the
> same problem, but without a References header and with a different
> Subject. I want to (manually) add it to the "bundle" and in the future
> view and process (such as mark as expirable) the whole bundle
> together. I would also like to store information related to the whole
> bundle (such as date of last activity in this thread/bundle). From what
> I know, there is no easy way to do that in Gnus.

My kludgy workaround for these things has been that I consider the
new message to be part of the old thread.  I then use `T ^' to
`attach' it to the thread.  I think it works like this: you select a
message which is to be the parent, hit `#' on it.  Then you select
the new message and hit `T ^' on that, and Lo!  The message is part of
the thread, with the #-marked message as parent.

-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: new backend?

[Ted Zlatanov]

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

Re: new backend?

[Kai Großjohann]

Ted Zlatanov <tzz@lifelogs.com> writes:

> 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've been thinking that it might be nice to allow for dynamic
creation of digests in a group.  You process-mark some articles, hit
a button, and lo! you get a new article which is a digest of the
process-marked ones which are then deleted.

Later on, you add an article to such a digest.

Digests can easily be viewed with C-d, so I think that would be a
nifty thing to have.

Not that it solves Jan's problems, of course.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

Re: new backend?

[Ted Zlatanov]

On Fri, 06 Dec 2002, kai.grossjohann@uni-duisburg.de wrote:
> I've been thinking that it might be nice to allow for dynamic
> creation of digests in a group.  You process-mark some articles, hit
> a button, and lo! you get a new article which is a digest of the
> process-marked ones which are then deleted.
> 
> Later on, you add an article to such a digest.
> 
> Digests can easily be viewed with C-d, so I think that would be a
> nifty thing to have.

Definitely.

> Not that it solves Jan's problems, of course.

I'll let Jan tell us, but I think that digest messages would be
exactly the right solution in this case.  Baing able to access these
digests by name as external move/copy targets would pretty much do the
"bundle" functionality.  I like it.

Ted