Developers of Sympa

[Guillaume Rousse <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.

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.

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 ?

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.

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

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)

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.

--
Guillaume Rousse
INRIA, Direction des systèmes d'information
Domaine de Voluceau
Rocquencourt - BP 105
78153 Le Chesnay
Tel: 01 39 63 58 31

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