Developers of Sympa

[IKEDA Soji <address@concealed>]

On Tue, 05 Mar 2013 17:34:28 +0100
David Verdin <address@concealed> wrote:

> Dear all,
> 
> With the upcoming install of Sympa 6.2 on our production server (next 
> week), the subsequent beta phase and the load of mails we received from 
> contributors / users / funders, I feel it is time to start putting 
> together our thoughts about Sympa for the next couple of years.
> 
> 
>     Development plans
> 
> 
> Here are our plans of development. These are RENATER project, but you 
> may have your own that can certainly find their place in the roadmap:
> 
> 
>         Features
> 
>   * Sympa in SaaS mode. We want to allow full virtual hosting of a Sympa
>     service. That means a lot of evolutions for scalability concerns and
>     new robot deployment. It will also require to make the largest part
>     of Sympa functionnalities accessible through the web and / or web
>     services (REST, SOAP). This is our next big step for Sympa 6.3.

Though I can't clearly grasp what "SaaS" means..., anyway, I believe
Sympa should be more modular.

For example, Mailman style "message pipeline" into which arbitrary
handlers to process or modify messages can be easily added.


About terminology: I love "robot" or "bot", but as Guillaume pointed
out, the word tend to refer to the active agents such as Web spiders.
# As Sympa "robot" is passive agent having (in general) multiple
# virtual hosts for e-mail, Web and so on, it is not virtual host
# itself.
Anything more better might be.

>   * RFC 6729 <http://tools.ietf.org/html/rfc6729> implementation. This
>     RFC allows to add "Received by" headers with richer information,
>     such as "kept for moderation". This will greatly improve tracability
>     of message in mailing lists.

Sounds good.

>   * RFC 5983 <http://tools.ietf.org/html/rfc5983> implementation. This
>     RFC deals with i18n addresses and mailing lists. I think Sympa
>     should implement it. I wonder whether Soji would have any advice
>     about this implementation, which look tricky...

Very interesting!  I'll investigate RFC 6783 (successor of 5983) and
relating RFCs.

>   * Potentially: changing our configuration file formalism to switch to
>     something more common, such as YAML <http://www.yaml.org>. We could
>     unify our configuration files and base them on CPAN modules instead
>     of our current home made parsers.

I agree a Babel on Sympa config formats should be solved.
I prefer to human-readable and human-writable format such as YAML.

BTW I'm wondering structured file formats are really needed.
Even simple "key = value" format may be able to provide conditional
settings (such as use_XXX or XXX_feature in current Sympa config).

> This is what we really want to implement in the 6.3. Feel free to add 
> the features you think should be added to this version. For example, we 
> spoke about CSS 3 a while ago. It woul be great. Once we agree on 
> development plans, we'll add a roadmap to the Sympa web site, with a 
> section for Sympa 6.3 and another for releases after.

I'll reply to reminder of your mail in other days.

<<snip>>

Best regards,

-- 
株式会社 コンバージョン  セキュリティ&OSSソリューション部   池田荘児
〒231-0004　神奈川県横浜市中区元浜町3-21-2 ヘリオス関内ビル7F
e-mail address@concealed  TEL 045-640-3550
http://www.conversion.co.jp/