Developers of Sympa

[David Verdin <address@concealed>]

Hi Guillaume,

Le 19/09/13 19:18, Guillaume Rousse a écrit :

address@concealed">Le 19/09/2013 17:35, David Verdin a écrit :

Well, taht's it. I think I went through most of our recent discussion
and proposed a consensus. Here's to you now!

I'd prefer to sort issues, before we rush again into an endless discussion about minor API details.

No, it's not about having a discussion. I spent a lot of time digging through the discussions we had since several months and looked for the consensus points;
I would like to get rid of all these minor points, so that they are all out of our system. This way, they won't come back when we keep on working on the code.
So if you could please just validate all these proposals, this would really simplify our work.

address@concealed">
For me, they are two priorities:
1) fixing tests, especially compilation tests

Currently, 25 modules (on 75) don't compile properly, because of some trivial syntax errors, but also because of recursive dependencies: we have some design issue to solve here.

Our first goal should be than those two tests (compile_modules, compile_executables) have 100% correct results, and than no commit should be allowed to break them.

Indeed. That's the ongoing work of fixing the problems that arose when merging the two branches. I'm on it, too.

address@concealed">
2) discuss general concept representation
Soji introduced the following class hierarchy in 6.2 branch:

Site_r
|- List
|- Site
   |- Robot

I quite understand the Site and Robot concepts as different sets of configuration parameters, corresponding relatively to the global Sympa instance and to individual local overrides  of those configuration parameters, the same way an apache server has one global configuration, and may have multiple virtual hosts. Am I correct here ?

Yes!

address@concealed">
However:
a) I don't think we need an 'is a sort of' relationship (inheritance) between the two concepts: AFAIK, an apache virtual host is not a specialized kind of apache host. It's just a way to simulate a distinct web server from the outside, by overriding some specific configuration parameters (not all), depending of the context. They are different, apparented concepts, but without specialisation relationship.

We need the mechanism to express the fact that we can define configurations and software behaviour at different level : Site -> virtual host -> list.
The things you can define at each level :
- scenari
- configuration parameters
- templates (web and mail)
- edit_list.conf
- etc.

So the inheritance mechanism is a perfectly legitimate way to factorize reusable code at each of these levels.

address@concealed">
b) we should find better names for those concepts. For instance:
- Host and VirtualHost
- Configuration and Overlay
- etc...

Site is a very good name, because it represents what is defined for the whole Sympa instance. The "site" concept is therefore pertinent : the site is the place where you regroup all your virtual hosts;
Robot is badly named -the fault lying here in Sympa historic naming patterns - we should name it virtualhost, or vhost.

address@concealed">
c) I'm strongly opposed to storing anything variable in class variables. Even if can only have one unique Site, we should use an instance for this (singleton pattern, for design pattern addicts)

Works for me.

address@concealed">
Now; for the Site_r concept, I'm puzzled: what is a Site_r object supposed to be ? And how is a mailing-list a specific kind of Site_r ?

If Site_r is just a place holder for generic code, it should better get renamed as 'Object', 'ConfigurableObject' or some other name following 'qualifier-noun' pattern.

Site_default ?

address@concealed">

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

David Verdin Infrastructure pour les Services Informatiques
Tél : +33 2 23 23 69 71 Fax : +33 2 23 23 71 21   www.renater.fr	RENATER 263 Avenue du Gal Leclerc 35042 Rennes Cedex

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