Re: [mlmmj] [RFC] Muting and unmuting threads
Dragan Simic <[email protected]> Fri, 02 Feb 2024 12:03:51 +0100
| Newsgroups | org.mlmmj.mlmmj |
|---|---|
| Message-ID | <[email protected]> |
On 2024-02-02 11:40, Baptiste Daroussin wrote: > On Fri, Feb 02, 2024 at 08:24:29AM +0100, Dragan Simic wrote: >> It's well known that people often complain about subscribing >> to high-traffic mailing lists, which results in receiving a lot >> of unwanted messages, etc. A recent example of such complaints >> came from the git mailing list. [1] >> >> People often want to receive messages that belong to specific >> threads only, e.g. to those resulting from patches they send to >> the mailing list. Thus, I was thinking about extending mlmmj >> to support such features, e.g. by implementing new features and >> commands that configure a subscription to receive only replies >> to their own messages sent to the mailing list. >> >> Has something like this ever already appeared as a suggestion >> or a though? Any feedback would be much appreciated. >> >> [1] >> https://lore.kernel.org/git/[email protected]/T/#m24a25bfc7b9dbe3a7136f5fc2d8a472e0f5f20ce >> >> > On principle I am not against, as a user I would be a big consumer of > such a > feature ;) I'm glad that you like the idea. :) > The problem is on the implementation side, I haven't given it a long > thought > yet, but at first glance, it means we keep track of who sent what so > kind of a > database of the threads and who has replied anything on it, which means > an > forever growing database, which is something that does not exist by > design > in mlmmj, the closest being the archive, but it is not contextual. Of course, I've also concluded that the implementation wouldn't be easy. There would be a lot of data to store and process, which is a challenge. > The key strength in my opinion of mlmmj is its simplicity, this has a > risk to > bring in complexity so it needs to be carefully thought. Totally agreed. The implementation would have to be highly efficient and as simple as possible. > If we were to design such a feature in a mlmmj friendly way it would > mean: > - a new kind of suscibtion: nomail + exception basically > - each time a mail is sent by someone with the subscrption activated, > we need to > keep track of the thread (a list of message-id ?) > - how long should we keep track of this thread? can we purge somehow > this list ? > (configurable pace for mlmmj-maintd?) > > Open for ideas for how to implement this in a stupid and simple way. Very good points, thank you. I'll go through the mlmmj source code and get back with some ideas, so we can discuss this further.