Developers of Sympa

[David Verdin <address@concealed>]

Hi,

Le 07/03/13 15:20, Guillaume Rousse a écrit :

address@concealed">Le 05/03/2013 17:34, David Verdin a écrit :

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.

For myself, and probably for many other people, the term 'robot' refers to some kind of automatic web crawler, such as googlebot. Sympa seems to be the only place where this term refers (apparently) to an HTTP virtual host, and is not even used consistently, as the following terms seems to be used in the code:
- robot
- virtual robot
- domain
- virtual host

So please consider either dropping this historical terminology, in favor of something more mainstream, or at least ensure it is consistenty used everywhere in the code. It makes no sense to refers to 'virtual robot', if you don't have 'non-virtual robots' to make the difference useful.

Yes, that term really disturbed me when I first discovered Sympa.
We should switch to "chost", for example. That would remain short and be clearer.

address@concealed">

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.
  * 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.
  * 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...

  * 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.

They are multiple level of unifications configuration.

1) distinguish file parsing from configuration handling
Look at the multiple load_something* functions used to read configurations files, each basically returning an hashref after checking its content. There is almost one function by configuration file...

Basically, we should aim to have just one parsing function/backend/whatever for every kind of currently used configuration format (xml, key/value pairs, etc...), and handle consistency checking separatly.

I didn't had a chance to look at what has already been done in 6.2 branch, so the situation may have already improved.

Not from the configuration parsing side of the things.
Actually, there are two parsing functions: one for sympa.conf / robot.conf, and one for all the other files. All the ohter functions are simply calling the generic parsing function with a hash describing the expected keywords found in the file. It would therefore be easy to simply use the same generic function for sympa.conf / robot.conf. The thing is: this generic function is limited to one level of hierrachy. We should then improve it to allow infinite levels of hierarchy. Some data need to be richer than a single paragraph.

Another step of improvment would be to have a single configuration file, with sections, instead of our numerous config file. It would be easier for users to find what they need to check.

Finally, another point of improvment: We should probably set a better matching between list configuration and vhost/site configuration.

address@concealed">
2) merge the three different configurations locations constants

The default sympa sertup handle some part of the configuration under /etc, and some part undef $sympa_prefix/etc, resulting in 3 differents constants: CONFIG, WWSCONFIG and SYSCONFDIR, whereas a single one should be enough to identify each configuration file location.

WWSCONFIG can be removed already, as wwsympa.conf no longer exists.
we could certainly merge CONFIG and SYSCONFIG, especially if we merge all the config files into one.

address@concealed">
3) reduce the different configuration formats to a unique one
YAML, JSON, XML, INI, whatever, I don't really care (excepted XML than sux), but a unique and consistent format would really make configuration easier.

We would have XML configuration file over my dead body...
I definitely agree on a unified configuration format. Étienne had the biggest crunch on YAML. He can certainly remember us why.

But not XML.
XML config files lead to madness.

address@concealed">
Whereas 1 and 2 are quite transparent for end-users, 3 would introduce quite a drastic change. So I'd rather use a major version number change to make it more explicit: sympa 7.0.

Probably...
We can still improve our configuration hjandling in the meantime, with all that's been said in 1 and 2.

address@concealed">
The rest in another mail :)

I can't wait. ;)

--

A bug in Sympa? Quick! To the bug tracker!

David Verdin GIP RENATER - Direction Technique Service applicatifs aux utilisateurs Tél : +33 2 23 23 69 71

Attachment: smime.p7s
Description: Signature cryptographique S/MIME