Developers of Sympa

[Olivier Salaun - CRU <address@concealed>]

Hi Mark,

> >   1. Since your summary includes both text/plain and text/html parts, 
> > we think it should become the default summary format. It means
> >      that you shouldn't have to add an extra reception_mode (there 
> > are too many of them) and you don't have to manage extra
> >      @tabrcpthtmlsummary
>
> I had thought about that. The reason I thought an extra delivery type 
> was warranted was that I didn't want to break existing functionality.
> With a single summary delivery type, if a listmaster uses the html 
> template then there is no option for recipients to get a
> text-only summary. It's not important to most of my users, but I think 
> some people may be upset about having multipart/alternate
> messages forced on them.

It makes sense

> [....]
>
> >   2. You should define a subroutine that htmlizes variables ('&' 
> > changed to '&'...)
>
> I think an extra sub in tools.pl would be an appropriate place, if you 
> have no objections.

Maybe the &tools::escape_html() could be extended to perform this job.

> The people who asked for this functionality want even more.
> The next stage I'm working on is categorisation of messages based on 
> moderation and/or keywords in the subject line.

We had this kind of feature in mind for Sympa, but nothing started yet.

> This is so people will need to read even less of the summary in order 
> to get the information they need - e.g. people could
> skip past an "Acting Appointments" section, and focus on a "Lectures 
> and Seminars" section. What has been asked for is
> a mini-newsletter, in essence, with community input and automatic 
> categorisation which can be overridden by a moderator.
> [...]
> Important points on this:
> -  categorisation will only occur if the list is a categorised one 

Ok

> -  categorisation will occur automatically based on keywords in the 
> subject line, and/or moderator input (will require wwsympa and
> mail command alterations)

Ok

> -  an extra message header will be inserted to define the category

It should allow "classicaly" subscribed users (ie not in digest mode) to 
filter messages based on this header, which was the main usage we had 
for categorisation.

> -  Extra hashes will be populated by the digest processing stuff, and 
> passed with $param. These will identify which categories will be
> used in a particular summary, and which messages belong in each category.

Great.

List owners will have to populate a list of categories for their list 
via the web interface. The moderation web interface should propose a 
menu to choose the category for a message. It could be usefull to 
separate category IDs from category title ; this could make subject 
tagging easier and would allow internationalization (if required).

How do you imagine message authors would indicate a category in the 
message subject ?

For subscribers that don't have filterring facilities in their mail user 
agent, Sympa could propose categories of interrest to limit the messages 
sent to a subscriber.


If you have question about the code design...

--
Olivier Salaun
Comite Reseau des Universites