Thanks for the detailed review. Replies inline!
Stephen J. Turnbull wrote:
Pranjal Yadav writes:
Blog: prany.github.io
code: giitlab.com/godricglow/mailman
Sorry about the long brain dump. Pick some of the issues to address
now and save the rest for later.
I took a look at your blog. First I reviewed your proposal blog from
April 29 (http://prany.github.io/gsoc15.html), and had the following
thoughts.
1. I don't understand why the X-Original-To header field is checked
after To. I imagine there is a reason, but as this header is
non-standard, something needs to be said about its presumed
semantics and when you would expect it to appear, as well as what
MTAs implement it (I don't think Mailman itself does, at least not
in our upstream version).
I agree with you, I was checking for X-Original-To: due to some
confusion, I
read /mailman/config/schema and misunderstood the last part where it says
subsequent methods will be re-written with second headers and adding to
the confusion was systers implementation which too checked for both. will
check for To: in the header.
3. I'm not sure about the wisdom of having a separate named pipeline
for dlists. I agree with you that the actual pipeline should
include different handlers rather than trying to incorporate the
dlist logic in existing handlers. (Of course somebody may want to
refactor to exploit commonalities in the code, but IMO your best
strategy is to copy the whole calculate-recipients and decorate
Handlers and modify them as convenient.) However, Mailman already
allows per-list (2.x allowed per-message! dunno if 3 does)
pipelines.
So I'm thinking that maybe we should put the standard pipelines in
variables (a sort of pipeline registry), and *always* attach a
pipeline attribute to each list. To prevent a list from changing
the global objects for everybody, we could make pipelines tuples
rather than lists. (We would need to run that by Barry first,
though.)
I'm not sure how this would work so I will need a bit more explanation for
this comment. AFAIK all mailing lists are attached with a pipeline from
Base pipeline, Virgin-pipeline, Owner-pipeline or Posting-pipeline, mostly
all messages attach to the 'built-in' or simply default-posting-pipeline
initially. So how exactly should I create those registries from pipelines?
Adding another attribute to the mailing lists will be easy but replacing
lists as pipelines tuples is a pretty complex thought. We'll run it with
Barry
as you said and then I will post the necessary changes.
4. Since Thread.base_message_id is supposed to be a UUID, that (or a
hash) would be a reasonable primary key for the Thread. This
would lead to an interesting extension that any message could
become a new dlist. Don't know if that would be useful, but it
might be (often threads split).
Now, about the progress report blog of May 31
(http://prany.github.io/threads-for-dynamic-sublists.html). First a
few stylistic comments.
5. You start by saying that messages are not kept in a structure.
It's not obvious what you mean by that. Obviously there are
message and metadata classes defined in Mailman. I guess you mean
that you want a history of the messages which might simply be a
list of message-ids, or their hashes. However, your Thread class
in the proposal doesn't seem to keep any history.
By structure I simple meant any form of order/arrangement that can
be achieved, using history is one good way of doing so. However I simply
planned to make threads to do so.
6. I disagree with you about the use of the word conversation.
A *conversation* is an ambiguously defined collection of messages
that have various commonalities -- a time span, a topic, and a
group of participants, at least.
A *thread* is a collection of messages that can be arranged in a
DAG (or even a tree) by using the reply-to relationship (which may
be implemented using the In-Reply-To and/or References fields, but
I'm referring to the human concept of reply here).
A *dlist* is a collection of messages defined by having a
particular mailbox among their addressees.
As I see it, your goal is to *implement* conversations (or maybe a
better word is facilitate) using d-lists. I have no objection
at all to using conversation in that sense. However, it's
important to recognize that what a human thinks of as a
conversation is quite different from what a machine can implement
as a thread or a dlist.
Also, while you have the right to use whatever definitions you
want, I think most people who are well-versed in email semantics
and implementations will agree with the definition of thread I
gave, and also agree that dlists are something quite different.
That means you will have a difficult time communicating
