[mmgsoc] Pipermail Archive-UI

Terri Oda terri at zone12.com
Sat Jun 11 00:25:00 CEST 2011

Barry Warsaw wrote:
>> 2. Generation of conversations list pages:
>>     Suppose at one point, we have 100 pages containing conversations
>>     lists. When a new message arrives for archiving, we can just update one
>>     or two pages by inserting new entry corresponding to this conversation
>>     and removing old entry(only if it is present in those one or two
>>     pages). This will eventually leave static files of conversation lists in
>>     an inconsistent state. So, we have to rebuild more or all pages of
>>     conversations list as a cron job.
> I think we should explore again the performance of generating these pages on
> the fly.  As I mentioned to Andrew, if doing so would cause problems meeting
> the schedule, it shouldn't be the highest priority, but if you and he can
> somehow share the load, then I think it's worth exploring.  You'll have to
> figure out whether dynamic generation of the pages will be acceptable
> performance wise, and you'll need some way to cache the results, but if it
> works out, I think it could be quite powerful.

As Barry says... basically do what allows you to meet your schedule.

I'm wondering if it might not be easier to do this particular task 
dynamically, though: then you could just query the database and get the 
most up-to-date listing.  Would it be easier to write the code for that 
and then for the static code, use that same script to regenerate the 
conversation when a new message comes in?

Incidentally, how do you propose to do conversations in Mailman 3? 
Systers is using a modified codebase where conversations are separated 
using +conversation stuff stuck into the email address used for posting. 
  (So for example, I might post a job interview to systers+jobs at ... if I 
were posting a job to the mailing list).  You won't have that logic, so 
will you be using References:/In-Reply-To: combined with the subject 
line to approximate that?  It's considered a bit of a technical problem 
in general, but probably any approximation we use will be "good enough" 
to start.  I can't remember if we've talked about that before...


More information about the MMGSOC mailing list