Developers of Sympa

[David Verdin <address@concealed>]

Hi,

Le 30/09/13 17:51, Guillaume Rousse a écrit :

Le 24/09/2013 10:50, David Verdin a écrit :

Hi Guillaume,

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

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.

Some of these points are easy to conclude (style issues, notably), others will be more difficult as long as we don't have a workable code base to compare actual code. But OK, let's try to review them.

[..]

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.

I'm afraid you're confusing inheritance semantics ("is a sort of") with one of its side-effect (code factorization).

I'm not confusing them. I just find useful to ignore the classical inheritance semantics to reduce code size. Anyway, see below.

A mailing list is not a specific kind of virtual host, even if they share some traits (not *all*). In particular, you can not pass a mailing list object to a code expecting a virtual host object.

Here is an alternative concept hierarchy:
- ConfigurableObject
|- Site
|- VirtualHost
|- List

This way, a site, a virtual host and a list are all specific kind of configurable objects, but none is a subtype of any other. You got both code factorization, and proper object semantics.

OK, let's roll with this. We'll see how to maintain a correct level of facorization.

Actually, the exact relationship between these elements is not inheritance. It's composition.
A sympa server is a set of virtual hosts. Hosts themselves are a set of families and lists, and families are a set of lists. Lists are a set of users.
All these elements have their own configuration parameters and, in addition, get their defaults from their containing element.

I don't think that qualifies for a composite pattern, but if you know of a general development pattern that fits this description, I'll be more than happy to discover it!

Anyway, let's say this discussion is over and we stick to your proposal. We need to write actual code to see if this view correctly handles Sympa needs.

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.

The problem with this terminology (Site/VirtualHost) is that you're opposing two term pairs:
- Site vs Host
- '' vs Virtual

Basically, there is nothing in those names linking those concepts together. Hence my proposal of 'Host/VirtualHost'.

All virtual hosts are not actually virtual.
We consider it good practive, to create a robot (old denomination) even if you have only one list domain. this way, when you have to add a second list domain, you have no concurrency between your first domain configuration and the new one (specific host vlaues are held in the specific host configuration file, robot.conf).

So "virtualhost" is probably not the best choice. Why not:

ConfigurableElement
 |_ Server
 |_ Host
 |_ Family
 |_ List

Server contains the defaults applicable to all list domains, and Host the defaults applicable to any List created inside the Host.
This naming pattern has the added value to usee very different terms, making the lack of inheritance more obvious, if needed.

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.

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 ?

A list is still not a kind of 'Site default' :)

:-P

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

David Verdin Études et projets applicatifs
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