Developers of Sympa

[David Verdin <address@concealed>]

Hi,

Le 25/01/13 09:31, Marc Chantreux a écrit :

On Fri, Jan 25, 2013 at 02:14:32PM +0900, IKEDA Soji wrote:

To cross over process boundary, I suppose other mechanisms such
as shread memory (e.g. Cache::FastMMap) would be used by 6.3.

IMHO, the goal would be
* remove the DBMS: we really don't need it and it's anoying for
  administration (for example, i'm really sad i can't use git
  to store the history)

You mean: remove the RDBMS for caching purpose?
Because for a lot of things like, say data related to each other, using a relational storage looks like the best option to me.

We could have a look at the Cache:FastMap module.

* add a cache system which could be networkable because really huge
  sites could need a distributed infrastructure (i would choose redis)
* use robot and listname as prefix to gain the expected granuarity 

Tell me if I'm wrong, but the OO model developped by Soji (Site, Robot, List objects) seems to solve this issue.
Look at the 6.2 branch if you want to have a clear idea of how this works now.

* don't check the state of the configuration file in the FS: use
  temporary files and "push to cache" mechanism instead.

Looks very good to me.

rewrite the parser to speed the things up: a site with less than 500
lists (i think this is the majority of the sites) would run fast enougth
without any cache system.

Another likely point of improvement. We use our own parsing classes. they can certainly be improved.
By the way, I'm rethinking the CPAN thing (port modules to CPAN, replace legacy code by modules, etc.). I'll forward you some discussions I had with Mark Overmeer regarding this issue and I think we could probably progressively rewrite some modules:

1. we improve module granularity and decrease interdependecies. that's what Guillaume did and he has probably many ideas for further work towards this direction, haven't you, Guillaume?
   
2. when we have a coherent set of modules for a type of functionnalities, we could probably release them as CPAN modules.
   

The idea is to do this step by step, in order to be able to release new versions of Sympa with new features.

Anyway: Yesterday night, I had a meeting with me and the notes I have taken along the last months. I have narrowed what RENATER objectives are for next year in Sympa. I also tried to gather some points that look like interesting to you and all this could be a good start for a discussion regarding future developments in Sympa.

I'll try to put it in a concise form shortly and you send this. Look at this as a request for comment. We have two developements wich are really important but the rest is not mandatory.

My short term plans are these :

• next week: finish 6.2 debugging
• the week after: iterate over several upgrade scenario to see how well data are preserved when switching from a Sympa x.x to the 6.2
• two next weeks: put the server in production on our own instance. During these two weeks, I will also merge the current 6.2 branch to the trunk, along with what Guillamue did. that means that in roughly three-four weeks, we should have a trunk ready for new developments.
• After that, we should be ready to release a beta.
  

More later.

Best regards,

David

regards
marc 

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

David Verdin Services Applicatifs aux Utilisateurs Tel. +33 2 23 23 69 71 GIP RENATER

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