Annotations and such

Annotations and such

[Lars Magne Ingebrigtsen]

It might be time to deal with this issue.  If one doesn't show some
restraint, one might end up with a new bboard system.

So, here's my initial thoughts:  If you are a group of people, and you
do bug fixing (or whatever) from a common reservoir of bug reports (or
something), it might be nice to be able to add comments (or
annotations) to the reports.  However, we already have such a system,
and it's called "following up".  If people want to add comments to a
message, they can just cite the relevant parts and put the response
into the group.  If one would like to see it presented in a
"report-with-annotations" manner, then one can just write a new
backend to merge the original report with the followups and present it
in a nice, annotationny manner.

There!  Wasn't that simple?  :-)  

It would nice to be able to add a different form of annotations to
messages -- "status"-like annotations.  Like -- "fixed", "important
bug", "totally bogus report" and so on.  Things that say what the
status of the item is, in one way or another.  Then the user would be
able to say "give me a list of all bug reports that do not have the
'fixed' status set to 'yes'".  And so on.

I've started implementing this, but I'm not sure I'm going about this
the right way.  Take nnml as an example.  When `nnml-set-status' is
called with `article status value', nnml will then add a new Status
header to the head and put the status in that line.  (Of course, any
previous other statuses will be preserved, etc.)  When Gnus issues an
`nnml-request-status' with `article', nnml will return that status
line.  

The problem here is that this will be *slow* if users do things like
putting the status line into their summary lines, which I would
imagine that some people would want.  Gnus needs to be able to get at
these thingies in a very efficient manner...  Hm.  Should nnml keep a
separate article-status alist updated?  I hate replicating
information; things always get out of sync.  Uhmn...  I could put the
status line in the .overview lines...  Yes...  I could put it into the
optional last part...  But what about the other backends?  nnmbox
heads would have to be scanned for Status headers, and I'd hate to
slow down general header parsing just for those few groups that have
useful Status headers...

Hm.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Annotations and such

[Yair Friedman]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> 
> It would nice to be able to add a different form of annotations to
> messages -- "status"-like annotations.  Like -- "fixed", "important
> bug", "totally bogus report" and so on.  Things that say what the
> status of the item is, in one way or another.  Then the user would be
> able to say "give me a list of all bug reports that do not have the
> 'fixed' status set to 'yes'".  And so on.

This is almost what I'm looking for.
I see marked articles as types of unread articles.  Currently there are
only three types of unread, Spaces which are the truly unread
ones, dormant (?) which means (to me) an important question, wait to see
what answers it gets, and ticked(!) which means this is interesting,
keep it.  Adding more such unread subtypes with user defined marks
would be useful and won't add much complication to the code (I hope).


I hope this is not too confused, I probably need another cup of coffee.

--
Yair Friedman.                  John Bryce (Systems) 1984 Ltd.           
                                7 Hamarpeh St.                           
                                Har-Hotzvom Science Based Industry Campus
                                Jerusalem 97 774, Israel                 
<URL:mailto:YFriedma@JohnBryce.Co.Il>

Re: Annotations and such

[Wesley.Hardaker]

Yair Friedman <yfriedma@johnbryce.co.il> writes:

> Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> 
> > It would nice to be able to add a different form of annotations to
> > messages -- "status"-like annotations.  Like -- "fixed", "important
> > bug", "totally bogus report" and so on.  Things that say what the
> > status of the item is, in one way or another.  Then the user would be
> > able to say "give me a list of all bug reports that do not have the
> > 'fixed' status set to 'yes'".  And so on.
> 
> This is almost what I'm looking for.

Well, you both should take a look at 'req' or 'multi-req'.  Its a
package designed specifically to handle things like this, through use
of a mailing list.  It has 'status' type attributes, as well as a huge
slew of other features.  

I would think that gnus shouldn't be working towards this direction,
as this type of stuff should really be a seperate package...  However,
I'm sure your development of a similar package could easily surpass
the other one, as it's not really worked on much anymore I don't think
;-)

Wes

Re: Annotations and such

[Greg Stark]

Cool, i need this for my backend too.

The problem with nnml being slow is easy once we add another feature on the
red gnus todo list: the ability to add arbitrary headers to the overview files
of the backends. Then if you want to put the status bit in the summary line
for an nnml group and it's too slow for your taste, you just add the status
header to the overview file. 

Lars, please make sure you keep this reasonably abstract; my backend and other
intended uses like the gnats backend will want to use this feature to
interface to an existing "status flag" of some sort. This is another reason to
allow returning the information in the overview headers returned from the
backend; most of these applications will probably have a fast way of
retrieving these flags, at least mine does.

greg

Re: Annotations and such

[Lars Magne Ingebrigtsen]

Greg Stark <gsstark@mit.edu> writes:

> Lars, please make sure you keep this reasonably abstract; my backend
> and other intended uses like the gnats backend will want to use this
> feature to interface to an existing "status flag" of some sort. This
> is another reason to allow returning the information in the overview
> headers returned from the backend; most of these applications will
> probably have a fast way of retrieving these flags, at least mine
> does.

Yup.  I'm currently mulling over two possible ways to implement this.

1)  Put extra fields in the .overview and HEAD headers and then Gnus
will parse the information.  

There are two drawbacks -- it will be slow, and it might slow down
execution even for people who have no interest in annotations.  And
it's also non-trivial to do.

2)  Backends define a `nn*-request-labels' that returns a
article-label alist.  If article 23 has the labels "bug" set to "yes"
and "read" to "no", the element for 23 would be 

  (23 (bug . "yes") (read . "no"))

This would mean no overhead for users that don't use labels/status,
and would mean minimal parsing of the output by Gnus, so it would be
completely up to the backends to store this information in the manner
that is most efficient for them.  It's kinda un-Gnusey, though.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Annotations and such

[Per Abrahamsen]

Status is a bad name for a new mail header, it is already used by bsd
mail for storing read/seen status.  Try labels, no reason to invent a
new name for an existing (in other programs) feature.

BABYL already support labels, so I'd suggest you start with the
nnbabyl backend rather than nnml.  I think being compatible with RMAIL
on labels would be a good thing.

For nnml, I think which (extra) headers to store in the overview file
should be an user option.  I'd like to be able to store `To' and
perhaps `Cc' in the overview for mail groups.  You could use these
fast with scoring or summary generation.

I think the default should be that there is no implicit use of labels.
Labels can be used with limits, or score, or perhaps in the summary
line, but this must be activated explicitly by the user.  This way, it
doesn't matter that parsing nnmbox would be slower, as the extra
parsing is only done on the users request.

Another vaguely related issue is that I'd like to be able to (easily)
add a limit expression to nnvirtual groups.  This way, I could have a
virtual group for unfixed bug reports and another for solved problems.

Re: Annotations and such

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Status is a bad name for a new mail header, it is already used by bsd
> mail for storing read/seen status.  Try labels, no reason to invent a
> new name for an existing (in other programs) feature.

Right -- "label" it is.

> For nnml, I think which (extra) headers to store in the overview file
> should be an user option.  I'd like to be able to store `To' and
> perhaps `Cc' in the overview for mail groups.  You could use these
> fast with scoring or summary generation.

Yes, that would be useful, but I still haven't quite worked out how to
use the extra headers inside Gnus without adding too much
complexity.

> I think the default should be that there is no implicit use of labels.
> Labels can be used with limits, or score, or perhaps in the summary
> line, but this must be activated explicitly by the user.  This way, it
> doesn't matter that parsing nnmbox would be slower, as the extra
> parsing is only done on the users request.

Sure.  But if the label stuff slows things down too much, nobody will
use it.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Annotations and such

[Kai Grossjohann]

>>>>> Lars Magne Ingebrigtsen writes:

  Lars> So, here's my initial thoughts: If you are a group of people,
  Lars> and you do bug fixing (or whatever) from a common reservoir of
  Lars> bug reports (or something), it might be nice to be able to add
  Lars> comments (or annotations) to the reports.  However, we already
  Lars> have such a system, and it's called "following up".  If people
  Lars> want to add comments to a message, they can just cite the
  Lars> relevant parts and put the response into the group.  If one
  Lars> would like to see it presented in a "report-with-annotations"
  Lars> manner, then one can just write a new backend to merge the
  Lars> original report with the followups and present it in a nice,
  Lars> annotationny manner.

  Lars> There!  Wasn't that simple?  :-)  

First of all, lemme say that I've always wanted something like this,
so I'll be happy with whatever you come up with.  Anyhow, I'd like to
add my twopence, though...

Maybe I'm slow or something, but I miss the issues supporting
collaboration.  How would you deal with several people accessing the
same base of bug reports?  Or would these have to use nnmh since this
won't have many problems of people stomping over one another's active
(overview) files?

Also, I've got to admit that I'm less concerned with bug reports; more
with something else: todo items.  I'd say bug reports are a special
case of todo items ("do this ASAP, take as long as you need").

For me, a todo item is something that has a deadline and also maybe a
beginning date (I need to do this here, but I can only start with it
September 1, when John has sent me his mail).

I'm not at all sure about how to do something like this, though.
Maybe one would need a mechanism outside Gnus to change the "status"
("label") of an item from "sleeping" to "active"?

Or is this all so far outside the domain of Gnus that it makes no
sense to integrate this?

Thoughts, anyone?
kai
-- 
Life is hard and then you die.

Re: Annotations and such

[Lars Magne Ingebrigtsen]

Kai Grossjohann <grossjohann@ls6.informatik.uni-dortmund.de> writes:

> Maybe I'm slow or something, but I miss the issues supporting
> collaboration.  How would you deal with several people accessing the
> same base of bug reports?  Or would these have to use nnmh since this
> won't have many problems of people stomping over one another's active
> (overview) files?

Well, annotations/labels would be very useful especially when
collaborating, so there would have to be some type of file locking
thingies used.  Perhaps one could use Emacs' "soft" file locking stuff
to do that.  (That would require that everybody working on the project
all used Emacs, but doesn't everybody?  :-)  

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Annotations and such

[Andy Eskilsson]

These annotations, does they include possibility to add some kind of
keywords to articles/mails? Sort of ability to add 'computer'
'school', 'work', 'myPC' in different combinations, searcheable,
viewable (sort of, show me all articles regarding computer and myPC.. 

Humm thinking of it.. you could also have 'expirable', 'marked' and so
on as keywords..

	/Andy

p.s. How big is gnus now BTW.. is it so 'modularized'(woah buzzwords
galore) that you can easily grab a nnbackend form somewhere else and
put it in your load-path, and maybe remove those backends not used..

Maybe extracting some of the less used backends, and packaging them
for themselves.. naah.. humm.. well?

-- 
 Hi I am an alien .sig, and at the moment I am having sex to your
 mind, by looking at your smile I can see that you like it.

 Unsolicited commercial email is subject to an archival fee of $400.
 See <http://www.fukt.hk-r.se/~flognat/mail/> for more info.

Re: Annotations and such

[Lars Magne Ingebrigtsen]

Andy Eskilsson <flognat@fukt.hk-r.se> writes:

> These annotations, does they include possibility to add some kind of
> keywords to articles/mails? Sort of ability to add 'computer'
> 'school', 'work', 'myPC' in different combinations, searcheable,
> viewable (sort of, show me all articles regarding computer and myPC.. 

Yup.

> Humm thinking of it.. you could also have 'expirable', 'marked' and so
> on as keywords..

Yup.

> p.s. How big is gnus now BTW..

1.7Mb.

> is it so 'modularized'(woah buzzwords
> galore) that you can easily grab a nnbackend form somewhere else and
> put it in your load-path, and maybe remove those backends not used..

Yes.

> Maybe extracting some of the less used backends, and packaging them
> for themselves.. naah.. humm.. well?

Nah.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."