Developers of Sympa

[IKEDA Soji <address@concealed>]

Hi,

This code fragment is posted for my memorandom.  I don't wish to
discuss on this issue right now.

------------------------------------------------------------------------------
package Sympa;    # formerly Site_r

# Virtual methods to be implemented by deriving classes

# Parent object: (List, Family) => Robot => Site => none.
sub parent {die}

# Root path of configuration specific to each object.
sub dir {die}

# Composite method

# Get search path
sub get_search_path {    # Formerly get_etc_include_path()
    my $self    = shift;
    my %options = @_;

    my $subdir;
    if (exists $options{subdir}) {
        $subdir = '/' . $options{subdir};
    } else {
        $subdir = '';
    }

    my @lang_dirs;
    if (exists $options{lang}) {
        push @lang_dirs,
            map { '/' . $_ }
            grep { $_ } (
                Sympa::Language::lang2oldlocale($options{lang}),    # compat.
                Sympa::Language::implicated_langs($options{lang})
            );
    }
    unless ($options{lang_only}) {
        push @lang_dirs, '';
    }

    return [$self->_get_search_path($subdir, \@lang_dirs, %options)];
}

sub _get_search_path {
    my $self      = shift;    # Site, Robot, Family or List
    my $subdir    = shift;
    my $lang_dirs = shift;
    my %options   = @_;

    my @path;

    # Special case for family instance: Family directory supercedes list
    # configuration directory.
    if ($self->isa('Sympa::List') and $self->family) {
        push @path, map { $self->family->dir . $subdir . $_ } @$lang_dirs;
    }

    push @path, map { $self->dir . $subdir . $_ } @$lang_dirs;

    if ($self->parent) {
        push @path,
            $self->parent->_get_search_path($subir, $lang_dirs, %options);
    } else {
        push @path,
            map { Sympa::Constants::DEFAULTDIR . $subdir . $_ } @$lang_dirs;
    }

    return @path;
}

1;

------------------------------------------------------------------------------
package Sympa::Site;

use base qw(Sympa Class::Singleton);

sub parent {return}

sub dir {Sympa::Constants::SYSCONFDIR}

1;

------------------------------------------------------------------------------
package Sympa::Robot;

use base qw(Sympa);

sub parent { Sympa::Site->instance }

sub dir { shift->{etc} }

1;

------------------------------------------------------------------------------
package Sympa::Family;

use base qw(Sympa);

sub parent { shift->{robot} }

sub dir { shift->{dir} }

1;

------------------------------------------------------------------------------
package Sympa::List;

use base qw(Sympa);

sub parent { shift->{robot} }

sub dir { shift->{dir} }

1;

------------------------------------------------------------------------------

On Tue, 01 Oct 2013 17:25:13 +0200
David Verdin <address@concealed> wrote:

> 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! 
> > <https://sourcesup.renater.fr/tracker/?group_id=23>
> > RENATER logo
> > *David Verdin*
> > Études et projets applicatifs
> >
> > Tél : +33 2 23 23 69 71
> > Fax : +33 2 23 23 71 21
> >
> > www.renater.fr <http;//www.renater.fr>
> >     RENATER
> > 263 Avenue du Gal Leclerc
> > 35042 Rennes Cedex
> >
> >
> >


-- 
株式会社 コンバージョン  セキュリティ&OSSソリューション部   池田荘児
〒231-0004　神奈川県横浜市中区元浜町3-21-2 ヘリオス関内ビル7F
e-mail address@concealed  TEL 045-640-3550
http://www.conversion.co.jp/