> > > > Just some small comments:
> > > >
> > > > 1. This is only the part that will be used by the handlers when creating
> > the
> > > > new messags. (the equivalent of the Message class from DlistUtils)
> > >
> > > OK, I don't think I understand why existing mailman doesn't include the
> > > msgdata, but you need to. Can you explain it to me? (It's probably
> because
> > I
> > > don't know the mm3 code, but it will help us both if you can explain it.)
> > > What is in the metadata?
> > >
> >
> > Right not, mm3 only stores the following information for a certain message:
> > the message_id_hash, its path and the message_id, which are all found in the
> > msg param. I added the msgdata because it contains the 'thread_id' field,
> > which will be added by the one of the two handlers (either FirstDlist or
> > SecondDlist, as Sneha Priscilla called them), when the message gets there.
> >
>
> So, msg is an object, so why not just make the thread_id an attribute of the
> object? (I don't want us to get to far away from what mailman is doing, and
> that seems to be what mailman is doing with the other info about the message)
>
> I'm refering to
> moderator.py
> messages.py
Yes, theoretically that can be done. So than I should go with changing the initial dlist model and add the 'thread_id' to msg instead of adding it to the msgdata? This means that I will only have to keep in mind to search the thread_id in the msg object instead of the msgdata one, when doing the rest of the actions from DlistUtils.
> > > > Just some small comments:
> > > >
> > > > 1. This is only the part that will be used by the handlers when creating
> > the
> > > > new messags. (the equivalent of the Message class from DlistUtils)
> > >
> > > OK, I don't think I understand why existing mailman doesn't include the
> > > msgdata, but you need to. Can you explain it to me? (It's probably
> because
> > I
> > > don't know the mm3 code, but it will help us both if you can explain it.)
> > > What is in the metadata?
> > >
> >
> > Right not, mm3 only stores the following information for a certain message:
> > the message_id_hash, its path and the message_id, which are all found in the
> > msg param. I added the msgdata because it contains the 'thread_id' field,
> > which will be added by the one of the two handlers (either FirstDlist or
> > SecondDlist, as Sneha Priscilla called them), when the message gets there.
> >
>
> So, msg is an object, so why not just make the thread_id an attribute of the
> object? (I don't want us to get to far away from what mailman is doing, and
> that seems to be what mailman is doing with the other info about the message)
>
> I'm refering to
> moderator.py
> messages.py
Yes, theoretically that can be done. So than I should go with changing the initial dlist model and add the 'thread_id' to msg instead of adding it to the msgdata? This means that I will only have to keep in mind to search the thread_id in the msg object instead of the msgdata one, when doing the rest of the actions from DlistUtils.