From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 51D3C1F404; Tue, 23 Jan 2018 22:03:03 +0000 (UTC) Date: Tue, 23 Jan 2018 22:03:03 +0000 From: Eric Wong To: Dimid Duchovny Cc: msgthr-public@80x24.org Subject: Re: Feature Request: thread grouping Message-ID: <20180123220303.GA7222@80x24.org> References: <20180121234911.GA29238@whir> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: List-Id: Dimid Duchovny wrote: > > You're right. In my case the flow was: read emails from storage -> > > group to threads -> add thread field to storage. > > However, I guess it's an edge-case. > > On second thought, maybe it'd be better to have a more general solution. > > E.g. let the client run an arbitrary callback after adding a child. OK, I guess you managed to fit skeletons of all your messages in memory? > > Here's a quick POC: > > https://github.com/dimidd/msgthr/commit/1c701717d10879d492d8b55fb8ca2f1c53d7e13f (truncated output of "git show 1c701717d10879d492d8b55fb8ca2f1c53d7e13f" > add callback to Msgthr#add > > The motivation is to allow the client to have a custom code executed, > whenever a child is added. > > --- a/lib/msgthr.rb > +++ b/lib/msgthr.rb > @@ -166,12 +166,16 @@ class Msgthr > # but do not change existing links or loop > if prev && !cont.parent && !cont.has_descendent(prev) > prev.add_child(cont) > + yield(prev, cont) if block_given? > end > prev = cont > end > > # set parent of this message to be the last element in refs > - prev.add_child(cur) if prev > + if prev > + prev.add_child(cur) > + yield(prev, cur) if block_given? > + end > end > end OK, that seems generic enough and we can probably support it long-term, so I'm somewhat inclined to accept it... However, APIs encouraging/supporting folks to load their entire collection(*) of messages (even skeletons) into memory feels wrong to me. Can you come up with a use case where this is useful for a subset of messages? (*) I work with millions of emails > > P.S. I hope you don't mind I uploaded my fork to github. That's fine, I just add a new remote(*) to my .git/config, fetch and show. What I won't accept about GitHub is having it as a centralized and proprietary messaging system which forces participants to accept their ToS. I can't accept that; no single entity controls email, so that's what I stick with. (*) added this to my .git/config ==> .git/config <== [remote "dimidd"] url = https://github.com/dimidd/msgthr fetch = refs/heads/*:refs/remotes/dimidd/*