> Sure, but I was just thinking you could do a better job
> introducing it to other people since you wrote it :)
> I announce all releases of software I intend to support to ruby-talk.
> I'm sleepy so my English has deteriorated, will wait until tomorrow
> before releasing + announcement.
Hi Eric
Dimid Duchovny wrote:
> 2018-01-25 0:49 GMT+02:00 Eric Wong :
> > I noticed you're also working on a new lca branch, should we
> > wait for that, or are you good with things as-is?
>
> Thanks, I'm good. The lca branch is intended for a POC of my actual use case,
> Lowest Common Ancestor in email
2018-01-25 0:49 GMT+02:00 Eric Wong :
> Dimid Duchovny wrote:
>> > Can you also add documentation for this feature so I can make a
>> > release? Thanks again.
>>
>> Sure, let me know if it's clear enough:
>> https://github.com/dimidd/msgthr/commit/6a1d06abc6c42e504a83dca4420c1d5ef39f09d2.patch
>
Dimid Duchovny wrote:
> > Can you also add documentation for this feature so I can make a
> > release? Thanks again.
>
> Sure, let me know if it's clear enough:
> https://github.com/dimidd/msgthr/commit/6a1d06abc6c42e504a83dca4420c1d5ef39f09d2.patch
Thanks, that's fine and I've pushed to 80x24.
> Can you also add documentation for this feature so I can make a
> release? Thanks again.
Sure, let me know if it's clear enough:
https://github.com/dimidd/msgthr/commit/6a1d06abc6c42e504a83dca4420c1d5ef39f09d2.patch
I've tested with olddoc.
Dimid Duchovny wrote:
> Consider this flow:
> 1. querying the storage backend according to some criteria (e.g. a
> time range, a particular sender, etc.)
> 2. grouping the messages in the response to threads
>
> I'd rather show than tell, so here's a more elaborated example:
> https://github.com/
2018-01-24 0:03 GMT+02:00 Eric Wong :
> 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 s
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 arbi
Sorry, the link should be:
https://github.com/dimidd/msgthr/commit/1c701717d10879d492d8b55fb8ca2f1c53d7e13f.diff
2018-01-23 23:04 GMT+02:00 Dimid Duchovny :
> 2018-01-22 1:49 GMT+02:00 Eric Wong :
>> Dimid Duchovny wrote:
>>> However, I realized that the last step (walking) is redundant,
>>> sinc
2018-01-22 1:49 GMT+02:00 Eric Wong :
> Dimid Duchovny wrote:
>> However, I realized that the last step (walking) is redundant,
>> since that could be done by the library itself in the threading or
>> ordering stages.
>
> I think you want is best done in the storage/indexing stage;
> whereas msgth
Dimid Duchovny wrote:
> However, I realized that the last step (walking) is redundant,
> since that could be done by the library itself in the threading or
> ordering stages.
I think you want is best done in the storage/indexing stage;
whereas msgthr is intended for display/rendering results that
11 matches
Mail list logo
