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.