This is a request to be able to annotate messages. It should operate in a similar fashion to bug #12305, which is the equivalent for web pages.

Actually, I was going to file another bug on annotating message senders, but then I realised you might want to annotate just about anything. Anyway, as you may know annotations were suggested by JWZ in his Intertwingle proposal (http://www.mozilla.org/blue-sky/misc/199805/intertwingle.html), although this seems orthogonal to the link traversal part of this, although quite related. You might see annotations for the sender, for the sender's domain, etc, and you'd probably want to separate in the popup whether this is just for this message, for the whole sender, etc. I think the "content alteration" possibility of bug #12305 is possible under this as well, but only on a message by message basis.

You need to put HELP WANTED in the whiteboard for it to come up in the query link on the mailnews page. =)

Thanks for looking out for me (I wouldn't want to send these bugs into oblivion), but I think in this instance you're mistaken.

Certainly looks that way now. I'm sure it used to be the other way though. =)

You should be able to define your own "annotation domain" (ie the messages the annotation applies to) rather than mailnews trying to work out the possible scopes for you, because there's too many. For example, you might want to define an annotation for all .com.au senders, or all people "to or cc" a .gov or .mil. That's the sort of flexibility I'm referring to, because you just know someone will want it. These annotations can be used as popups or reminders. It would be really great to get a message saying "This guy called you a butt-kisser in public." =)

The annotation scope/domain should probably be defined using the same selection panel as is used for filters, for reusability reasons.

Bulk-resolving requests for enhancement as "later" to get them off the Seamonkey bug tracking radar. Even though these bugs are not "open" in bugzilla, we welcome fixes and improvements in these areas at any time. Mail/news RFEs continue to be tracked on http://www.mozilla.org/mailnews/jobs.html

Reopen mail/news HELP WANTED bugs and reassign to nobody@mozilla.org

I think we should make sure, that this info is stored in any standards-conformant way. For example, I am happy to have *all* important info on the IMAP server (safer, cross-platform). And not to be bound to any special mail reader. How about this: Create the annotation as a reply with special headers. Maybe the "To:" field could contain a special value, too, so that the user can easily see even in other mail readers, that this is an annotation. It wouldn't be easy to get the configurable scope thing into that scheme, but it should be possible, I think.

This feature looks very cool. My experience is zero, but I will browse through the source and see, if I can do something for this. Any hints/help welcome.

Is it "standards compliant" to use non-standard headers? I don't see you could immediately store it in messages in IMAP, since the most likely use is for attaching to senders, not messages. But I don't know IMAP. And you're still going to have a local storage mechanism for caching (I believe IMAP still has offline mail?) and non-IMAP implementations.

>Is it "standards compliant" to use non-standard headers? I think so (given, that the standard headers are included). Am I wrong? >since the most likely use is for attaching to senders, not messages. The opposite is true for me. Anyway, I think, annotations are initiated through messages, so we could create a reply with special headers, storing the "general scope". >And you're still going to have [...] non-IMAP implementations. Sure, this should work fine. IMAP was just an example/argument.

OK, I'll *try* to dig in. URL is http://www.bucksch.com/mozilla/12306. Help/comments etc. appreciated.

Hi Ben, if you are going to try to implement this feature, you may want to assign the bug to you :-) Thanks!

Sorry, I didn't read your original message properly, I thought you were talking about adding headers to messages, rather than separate replies. I think it's better to create a special folder that contains the annotations as a message each. This would allow mailers not supporting this to at least support the display of annotations easily, and can delete them. I think replies are not the best since they could confuse users and they also imply that an annotation is fixed to a specific small set of messages, which it shouldn't be. This folder should still be displayable through compliant mailers, since you could centrally read and maintain the annotations. Ideally you'd also be able to get a list of messages this annotation applies to. I think the presence of an annotation should be a column containing an exclamation mark of similar. My idea of annotations is a window that pops up. You would see a scope title and then the text, eg: --- From sender a@a.com --- blah blah -- This message --- blah blah --- Add Annotation Delete Annotation etc. Adding davidmc who might be interested and have suggestions.

I think, we're talking about different things. I'm thinking of annotations to exactly one message. This would mean, that they must be stored near the message, too. (1) This enables non-Moz-MUA-users to easily see the annotation (2) It keeps related data together (e.g. all info concerning project XY can be archived in one step). I see your general scope as an extention to this. An annotation folder would be appropriate for your comment from 08/23/99 19:26, I think.

Yes, and the desire to see a general facility implies that you should have a general mechanism (ie forward compatible), not two different ones. Even having only message annotation, I'm still not sure it's the best, for reasons like there is no easy way to find all annotations centrally, and it implies that they are replies, which they're not.

Why is my proposal not forward compatible? You just store the annotation in another folder. But you do (1) store more info (the scope) and (2) have to get the info from the user and (3) have to implement the events incl. handlers. Please go ahead any tell me your complete concept so I can keep it in mind or build it in. > there is no easy way to find all annotations centrally Why should you want to?

I think, I wasn't clear enough: You could easily store message-related annotation in the message folder and annotation with a general scope in a special annotations folder, as you suggest.

See ref to "transclusion" in Ted Nelson's Xanadu, at http://www.xanadu.net/zigzag/ and http://www.byte.com/nntp/joncon?comment_id=1701 I mention these only to give you a place to go look and have even more ideas than you currently have; I don't mean to patronize, or imply Nelson's ideas are better than anyone else's, or that yours and mine are not in fact better. It's just grist for the mill. I will add another comment in a moment.

I have written some things before about the variety of techniques to achieve the effect of associating two pieces of data; so the idea of annotation is a particular application of this general notion. I expect that many folks easily come up with very similar ideas about what is desirable to see in a user interface that supports annotation and can usefully merge together disparate data sources. So none of my comments are ever aimed at trying to say something first so I can show the novelty of my thinking. :-) Instead my comments aim to groan about practical aspects of plumbing, and to reduce any problems and risks that can arise from specific designs that are suggested. Let's stipulate that the act of storing annotations someplace is not very hard, and that if you take care to use a schema-less database of some kind or another, then you leave yourself open at all times to add new kinds of annotation without breaking old formats. So it is going to be the other effects that are hard to control, and the common theme is all the things that can go wrong with maintaining synchronization either between base data and annotation data, or between annotation data and archives of annotation data. It seems this has already been discussed by Ben and Matty. Please go on doing this analysis, because the hard part will be assigning priorities about what things matter more, because some choices will be necessary. A particular design has to arise out of some weighting of which things matter most to you, whether it is shared access, or resistance to bad data or out-of-sync data, or ease and cheapness of archiving, or tidy presentation in a rational way to end users, etc, etc. So my input will tend to focus on adding shades of gray on such stuff, and maybe a little on the implications of storage choices. So what do you want me to say? What do you see as problems? What questions do you want answered more than others right now?

I've read the articles, but I couldn't see any relation to our problem, since they propose are completely new worlds. What do you mean by "schema-less database" any how would it look like? As I already pointed out, I think, the location and format of storage is essential. Although, of course, these are not the only key attributes. Extensible designs are what I normally vote for, too. If anybody could give ideas how to do create this, I'd like to hear that. Real extensible design are hard to create, since you have to make things possible, which you can't think of. At the moment, all "extentions" I can think of are the proposals of Matty, which I respect as fully valid. I've just no use for them and no motivation to implement them, since I think, that they need a lot of _additional_ work to message annotations. I still have no concrete impression, what Matty thinks, how to implement it, but as far as I see it, there's no problem in extending message annotation as I planned them to the more general messaging annotations (including Matty's proposals). The only problem I see at the moment is, as David pointed out, syncronisation. I think, we shouldn't store annotations in the original message (since then, it wouldn't be "original" anymore :-)), so we need to keep track of message copying/deleting. The real problems in implementing this are (1) understanding the current code and (2) the danger of forgetting something. Please see the homepage for the project, too.

If there're any comments on the design, please articulate them now, since I'm already evalutaing the implementation.

> I've read the articles, but I couldn't see any relation to > our problem, since they propose are completely new worlds. Sorry, I thought Nelson's "transclusion" idea would suggest some avenues of thought. Ignoring that, the general idea concerns how to join two separately stored pieces of data as if they had stored together in the first place. Annotation amounts to giving objects new attributes. There's no reason why attributes could not be stored just about anywhere. So the annotation model will be well-defined if you specify in what way an annotation db provides addtitional attributes for remote objects. > What do you mean by "schema-less database" any how would it look like? That means the number of attributes for any object is unbounded, so you can always add more. A database design using a schema usually does so in order to develop fixed performance strategies based upon knowing that extensions will never occur. This trades off extensibility for speed and space optimization, neither of which are that critical any more today, because hardware is much faster and capacity is much greater. > As I already pointed out, I think, the location and format of storage > is essential. Although, of course, these are not the only key attributes. I think the interface is more important than the location and format. This actually makes both of them mutable and extensible, which is part of the point when one is extending objects with new attributes. Personally I care a lot about formats, but I never seem to meet anyone who actually understands any format designs I create, to the extent they see why I made certain choices. So I view emphasis on format with some suspicion, since I expect someone to then settle for a fixed system that holds no interest for me. If you pick a non-extensible format, then I would tend to ignore everything after that point. > Extensible designs are what I normally vote for, too. If anybody could > give ideas how to do create this, I'd like to hear that. Real extensible > design are hard to create, since you have to make things possible, > which you can't think of. You might check out my months stale IronDoc site, which has much more material on database stuff than you'd probably like to read: http://www.best.com/~mccusker/irondoc/irondoc.htm http://www.best.com/~mccusker/irondoc/query/whatis/qwfe.htm One main theme in my IronDoc work was extensibility. So I have a notion I know a lot about this, but I lack the verve to play an authoritarian on the topic. However, the main techniques involved are using attribute value pairs, and designating almost everything using names so that the set of denotable things is both very large and flexible. > At the moment, all "extentions" I can think of are the proposals > of Matty, which I respect as fully valid. I guess I didn't grasp them when I read the first time. > I've just no use for them and no motivation to implement them, since > I think, that they need a lot of _additional_ work to message > annotations. I still have no concrete impression, what Matty thinks, > how to implement it, but as far as I see it, there's no problem in > extending message annotation as I planned them to the more general > messaging annotations (including Matty's proposals). I keep the position that actually storing annotations is a much less delicate problem than how to control the usage of these with respect to the remote content that is being annotated. > The only problem I see at the moment is, as David pointed out, > syncronisation. I think, we shouldn't store annotations in the > original message (since then, it wouldn't be "original" anymore :-)), > so we need to keep track of message copying/deleting. Annotations should be stored separately. Each message has an identity, which distinguishes it from another. Each annotation would also say the identity of the message which it annotates, so one can look up whether any given message has some annotation. > The real problems in implementing this are (1) understanding > the current code and (2) the danger of forgetting something. There is also a danger of not having a definite plan, since some things cannot work well by following the algorithm of removing annoyances as they arise. Sometimes the process does not converge on a done state when one plans to fix conflicts as they come up in practice, instead of defining how conflicts cannot happen in the first place. I might not be able to say much more about this problem, but I might kibitz at random. I'm confused about how the implementation can be underway when I don't see that the design has been roughed out. But maybe I just don't get your normal coding practice.

I think we're blowing up BugZilla, it is really is no discussion platform. Additionally, I get the impression, we're all talking about different things. We should look for another medium. What about Chat? I'm pretty tired right now (it's 0:28 here), what about tomorrow morning (WST)? I'm usually on #mozilla, too. I hope to be able to read the docs you pointed me to. Please be sure to read this thread and the project homepage (URL field) again. I'll do the same.

It would be okay to discuss in n.p.m.mail-news. I have never used any kind of chat because I prefer slower mediums, and dislike anything which requires that my attention track something. It's as if I detest immediacy. :-) I am happy not existing as far as chat is concerned.

Ben the reason I say "not forward compatible" is that I think you should have a general mechanism and therefore if you made them replies you couldn't easily change it to later where all messages are in the annotations folder. Perhaps it's not the best terminology to use. I don't really care what you do in the UI since it's easy to change later, but when I think about placing one type of annotation in one place and another in another, alarm bells start going off in my mind. I can see it might be a problem to put a header on the annotation, and then need to work out what folder it's in. David could say more about what's involved here. As for central viewing of annotations, I can imagine various situations where I might want to browse the annotations centrally, such as deleting old annotations. Furthermore, having an annotation is a way of getting into the message as well - if you "opened" it, you might go to the message. It might be easier to find your message by browsing the annotations than all the messages.

If you store all annotations as special messages in one folder, they're not very different from replys as well. Replys are just new messages with a reference to the original one and maybe quoted text. And this is exactly, what we want (at least what I think we want). > when I think about placing one type of annotation in one place and another in > another, alarm bells start going off in my mind. Could you please explain that further? I see no real problem there. > As for central viewing of annotations, I can imagine various situations where > I might want to browse the annotations centrally, such as deleting old > annotations. Why should you want to look for annotations to delete. I look for messages (and related annotations) to delete or, and that's key here, for entire folders of messages to delete/archive. > It might be easier to find your message by browsing the annotations than all > the messages. As pointed out on the homepage, it is possible to change the icon of the message to indicate the annotation. For attachments, it would make much more sense to store them separately than for annotations (size), but they're stored in the messages, too. And I consider it as good. I want different folders being _completely_ separated, including all related data. How do you want to treat non-Moz-MUAs? If you store all annotation in one folder, it's nearly impossible for the user to recreate relations manually.

> when I think about placing one type of annotation in one place and another in > another, alarm bells start going off in my mind. Could you please explain that further? I see no real problem there. I think I should make that clearer. We're talking about two completely different types of annotations here. Apart from storage, message annotations have more in common with web annoantions than the general scope messaging annotations. Message annotation are attached just to an object, while the general scope annotations can be considered as annotations to expressions. The only things they have in common are the nature of being a text (message) and that they're maybe a reaction of a message (a kind of reply) with quotes.

David, I must admid I fear a discussion on usenet. They typically need 2 weeks, and I have, as bad as this sounds, not the time for that. I both don't what to wait for comments several weeks (until the thread is closed) and want this to be shipped with 5.0 and IIRC, the deadline for features is 19. this month. But this doesn't mean I dislike design or discussion. This is the reason I discuss with you (both). It's just the medium which makes problems, because there's no threading.

If bugzilla is like the old Netscape bugsplat, then eventually the bug text will fill up and truncate any additions, which can only be fixed by editing down the body of the bug report. This is just a warning to help explain, in case someone sees what looks like this behavior; I don't know if limits still apply. Is the propagation delay for usenet a problem? Or do you just worry that you must actually give folks more time when discussing in that venue? I was just looking for a place to exchange dialog with you; I'm not concerned about whether other folks get their own say. They can either keep up to your pace or you can ignore them; there's no need to let anyone hold you back. Also, you can never tell when somebody might make what seems a very useful suggetion.

> If you store all annotations as special messages in one folder, they're > not very different from replys as well. Not using the standard headers would cause non-compliant mailers to not show them as replies - I think this is a good thing. I don't see a real problem with not being able to find annotations from a message with a non-compliant mailer, if they want to, they can add the feature. Putting it a central folder reduces the folderspace pollution from the non-standard extension. Though I think the main question is which folder they're stored in. > Could you please explain that further? I see no real problem there. I don't like the idea of one type of annotation being stored as replies in the same folder, and others just being standalone messages in another. > Why should you want to look for annotations to delete. I look for > messages (and related annotations) to delete or, and that's key here, > for entire folders of messages to delete/archive. Not so much for one-message annotations, but certainly for general annotations you'd want to do that. I guess there is a distinct difference though. Because per-message annotations are linked to a single message they can and should be deleted along with the message. > As pointed out on the homepage, it is possible to change the icon of the > message to indicate the annotation. Yes but what if you have a thousand messages in tens of folders with an annotation you could quickly recognise? A search facility could certainly help, but I think direct browsing is still desirable. This can probably be done with some sort of virtual folder with your way though. > For attachments, it would make much more sense to store them separately > than for annotations (size), but they're stored in the messages, too. And > I consider it as good. But attachments ARE part of the message, and they have identity issues (you've seen bug #9413). They won't necessarily be stored "in the message" though, that's up to the message store. Obviously it has to look like it is over POP and IMAP though. > I want different folders being _completely_ separated, including > all related data. What about annotations whose scope is within a folder? Do these get stored in the folder as standalone? What if it applies to a folder or it's subfolder? Does it get stored in the highest folder? These are all possibilities, but the make it more complicated. You can only evaluate this is terms of user usage. For compliant mailers, the issue is simplicity and efficiency of implementation, since they can do anything in the UI. For non-compliant mailers, the issue is how it will appear to the user. I think efficiency needs to be discussed, particularly over IMAP. What operations are efficient? How easy would it be to locate an annotation for a message in a central folder? In the same folder? > How do you want to treat non-Moz-MUAs? If you store all annotation in > one folder, it's nearly impossible for the user to recreate relations > manually. I'm not sure I understand what you mean. What relations?

> Not using the standard headers would cause non-compliant mailers to not show > them as replies - I think this is a good thing. I do not. > I don't see a real problem with > not being able to find annotations from a message with a non-compliant mailer, > if they want to, they can add the feature. LOL > Though I think the main question is which folder they're stored in. At the moment. But, as David indicated, we should concentrate on other goal, too. >> Could you please explain that further? I see no real problem there. > I don't like the idea of one type of annotation being stored as replies in the > same folder, and others just being standalone messages in another. This is no explanation, this is a statement. > I want different folders being _completely_ separated, including > all related data. > What about annotations whose scope is within a folder? Do these get stored in > the folder as standalone? What if it applies to a folder or it's subfolder? > Does it get stored in the highest folder? These are all possibilities, but > the make it more complicated. I'm speaking of annotations to exactly one message. Not Folders, not Recipients. Every bjond that, I consider as belonging to your general scope idea, which I have no time to implement. Deadline is in 11 days! > I think efficiency needs to be discussed, particularly over IMAP. What > operations are efficient? How easy would it be to locate an annotation for a > message in a central folder? In the same folder? Keeping messages and annotations together would be far more efficient, because it's only one folder which has to be connected to. But I don't think, that'S so much an issue. >> How do you want to treat non-Moz-MUAs? If you store all annotation in >> one folder, it's nearly impossible for the user to recreate relations >> manually. > I'm not sure I understand what you mean. What relations? The message, to which the annotation refers. If you store all annotations in one folder and you have, say 50 annotations to 50 of 1000 messages, how qould the user be able to see, (1) to which message the annotation refers or (2) that there's an annotation to the message he's viewing? If annotations are replys in the same folder, *any* MUA can present the relations correctly.

>> I don't like the idea of one type of annotation being stored as replies in >> the same folder, and others just being standalone messages in another. > This is no explanation, this is a statement. The point is that general mechanisms tend to be easier to implement, understand, maintain and tend to have less bugs, as opposed to many case mechanisms, or general mechanisms with special cases. Putting them all in one place would make it more general since getting an annotation is simpler. What I'm concerned about is a design decision now can't be easily changed later if people are using this feature. I don't think 11 days is enough time to consider the issues. > I'm speaking of annotations to exactly one message. Not Folders, not > Recipients. Every bjond that, I consider as belonging to your general > scope idea, which I have no time to implement. I know, but I think it's important to hash out the general design now before implementing the subset. Hence I think it's better if the message annotation feature is designed to try to be consistent with all messaging annotations. > Keeping messages and annotations together would be far more efficient, > because it's only one folder which has to be connected to. But I don't > think, that'S so much an issue. I imagine a lookup on one folder would be, but the question is by how much (is it worthwhile as an optimisation on this case)? Are searches on multiple folders in general inefficient? Does IMAP have a high-level primitive to do it, allowing IMAP servers to be efficient on multi-folder searches? How easy is it to look one up from the other? > how qould the user be able to see By looking at headers, if interested. > there's an annotation to the message he's viewing? If annotations are > replys in the same folder, *any* MUA can present the relations correctly. I know, but I don't think this is desirable, since non-compliant mailers can't distinguish between a reply and an annotation. I guess it's a touchy-feely impression. I'm not even sure I care about non-compliant mailers, since we're hardly going to break them.

Discussion is going on in n.p.m.mail.news http://x45.deja.com/viewthread.xp?AN=522575868&search=thread Changed "Component" to "Back End"

The attachments represent the current state of work. Work is haltet at the moment in favor of bug #13678.

Moving to M20 till I have a more concrete impression of timeline.

Dependency on bug #13678.

Mass-LATER

Ben - is this LATER because you can't work on this now? If so, perhaps add to "helpwanted" list? Just trying to understand since usually "resolved" (even bugs at a later resolution) bugs tend to get lost because no one searches for bugs that are resolved. Thanks.

agreed. REOPEN, helpwanted

I think the query for helpwanted may also search for assigned to as: nobody@mozilla.org. You may want to change the assignee to that and then add yourself to the cc: list.

Lisa, you're speaking about <http://www.mozilla.org/mailnews/jobs.html>? It does show up in the query linked from there.

You are right, Ben. I was just thinking that if the assignee showed someone's name, a person looking / glancing through the list may think that the bug is already taken. This is just me being picky :-)

I'm still a bit interested in this bug, but not in the moment, so yuo may be right... REASSIGNing

Moving feature bugs to target milestone "Future" for next release consideration.

*** Bug 183002 has been marked as a duplicate of this bug. ***

See also the IMAP Annotation draft at <http://www.ietf.org/proceedings/00dec/I-D/draft-ietf-imapext-annotate-00.txt>.

See also Thunderbird bug 254739.

Filter on "Nobody_NScomTLD_20080620"

Is anyone still working on this? I used the addon Xnotes for that purpose, but this project kinda died and is not usable with thunderbird v3 any more. I would really appreciate if this feature would be added soon. And BTW: I don't think using IMAP features for this is a good idea because it should work with POP as well.

Wow, this bug had only 5 digits. Would be great if someone could make it work :)

Very often I have the need to comment emails in my inbox for my own use. This is helpful if I later look into the mail. For example I have a mail with the text "ok, I'll promise I will do it" and I would like to add the note "asked him on phone to give me 1000 dollars". Also, it would be nice to mark the mail with a date, for example how long it is valid. Let's say I get a mail with an invitation to a party on 1mar2013, so I would keep that mail and mark it to be deleted on 2MAR2013. This could be done with some extra headers which are stored with the mail. For example X-Mozilla-Comment: asked him on phone to give me 1000 dollars

The rfc backend which could support this in a shareable way is bug 288514. The "standalone notes" complement to this bug is bug 116945.