Developers of Sympa

[Guillaume Rousse <address@concealed>]

Le 12/08/2013 08:01, IKEDA Soji a écrit :
> Hi,
>
> While grandma is cutting a cake, I'd like to make decision
> on convention about spool objects.
>
> # Honestly, I prefer to use implementation based on filesystem
> # for all spools.  I worry SQL-based implementation is efficient
> # enough, especially to handle 10MB or larger messages).
> # So it is important for me Sympa-7 can use both implementation.
>
> Current convention:
>
>      my $spool = Sympa::Spool::SQL->new(
>          name => 'digest',
>          base => Sympa::Database->get_singleton()
>      );
>      my $spool = Sympa::Spool::File::Message->new();
>      my $spool = Sympa::Spool::File::Task->new();
>      my $spool = Sympa::Spool::File->new('outgoing');
That's not really a convention, rather just the need to keep the code 
compiling. I perfectly agree than backend implementation class should 
not be hardcoded if we need to make it configurable.

> I'd like to propose as following:
>
> o Spool class would be handled in single style:
>
>      my $spool = Sympa::Spool::Digest->new();
>      my $spool = Sympa::Spool::Incoming->new();
>      my $spool = Sympa::Spool::Task->new();
>      my $spool = Sympa::Spool::Archiving->new();
'Task' and 'Digest' are nouns, whereas 'Archiving' and 'Incoming' are 
not, this is not consistent. I guess incoming spool is meant to store 
messages, so that should rather be:
my $incoming = Sympa::Spool::Message->new();

> o Each class is a subclass of common abstract class (i.e.
>    Sympa::Spool) and has following variations:
>
>     (1) Content object to handle (message digest, Message, Task, ...),
>       defined by each class itself.
>     (2) Physical backend (SQL, filesystem, ...) defined by configuration
>       option.
>     (3) Domain in the backend (on SQL, value of name_spool column;
>       on filesystem, name of subdirectories: "digest", "msg", "task",
>       ...) defined by each class itself.
It would be clearer to enumerate the needed classes, and to define their 
exact relationships. For instance, how will you manage backends ? Yet 
another class hierarchy ?

And I still object having spool classes hardcoding their settings, which 
tends to multiply artificially the number of classes needed. If you 
hardcode the fact than spool 'X' uses domain 'X' in a Sympa::Spool::X 
class, than you'll need as much classes as you have spools. For me, 
those settings should be passed at instanciation time by calling code, ie:

my $incoming = Sympa::Spool::Message->new(
    storage => $configuration->get_param('spool_storage'),
    domain  => 'incoming',
    name    => 'incoming'
);

> o Configuration parameters for (2) above would be defined for
>    each spool.  Current possible values are "sql" and "filesystem".
>
>     digest_spool_storage
>     incoming_spool_storage
>     task_spool_storage
>     ...
>
> Any comments?
Is it really needed to mix spool storage type ? What about first getting 
a simple, but working implementation, before reaching into unproven 
complexity ?
--
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