Subject: Developers of Sympa
List archive
Re: [sympa-developpers] [sympa-commits] sympa[9263] branches/sympa-6.2-branch/src: [-dev] Messagespool has its own constructor new()
- From: Guillaume Rousse <address@concealed>
- To: address@concealed
- Subject: Re: [sympa-developpers] [sympa-commits] sympa[9263] branches/sympa-6.2-branch/src: [-dev] Messagespool has its own constructor new()
- Date: Fri, 24 May 2013 14:12:04 +0200
Le 24/05/2013 12:26, Marc Chantreux a écrit :
Hello,I prefer this class hierarchy, which clearly separates concerns.
The way i see things: Spool have 2 roles:
* What to store (Message, ...)
* How to store (SQL, ...)
so the way i would like to see things is:
Sympa::Spool->new(qw[ for Messages by SQL ]);
Will create a Spool for
Sympa::Spool::for::Messages
backed end by
Sympa::Spool::by::SQL
Sympa::Message::Spool->new will just honor the config
Sympa::Message::Spool->new
( by => [qw[ File serialize YAML root /tmp/sympa/spool ]] )
Will create a Spool for
Sympa::Spool::for::Messages
backed end by
Sympa::Spool::by::SQL
so we can use roles to check that required are implemented
However, what I realised in the mean time was than there is no evidence we need to have so many classes.
We do need to have distinct classes for backend type, sharing a common interface, so as to have an abstraction layer for calling code: the sympa daemon should be able to manage incoming message spool transparently, wether file-backed or sql-backed.
However, is there any interest to have some abstraction over spool content (message, key, whatever) ? After all, the calling code usually know which is expected content over each spool...
So, if it's help making the code simpler, we could keep using only three classes:
Sympa::Spool
Sympa::Spool::File
Sympa::Spool::SQL
And have each of the two final classes implement distinct methods for storing distinct kind of content:
Sympa::Spool::File::add_message()
Sympa::Spool::File::add_key()
Sympa::Spool::File::add_something_else()
Sympa::Spool::SQL::add_message()
Sympa::Spool::SQL::add_key()
Sympa::Spool::SQL::add_something_else()
This doesn't prevent to have mixed-content spool by mistake, but code readability also helps to prevent coding errors :)
--
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
-
Re: [sympa-developpers] [sympa-commits] sympa[9263] branches/sympa-6.2-branch/src: [-dev] Messagespool has its own constructor new(),
Guillaume Rousse, 05/23/2013
-
Re: [sympa-developpers] [sympa-commits] sympa[9263] branches/sympa-6.2-branch/src: [-dev] Messagespool has its own constructor new(),
IKEDA Soji, 05/23/2013
-
Re: [sympa-developpers] [sympa-commits] sympa[9263] branches/sympa-6.2-branch/src: [-dev] Messagespool has its own constructor new(),
Guillaume Rousse, 05/23/2013
-
Message not available
-
Re: [sympa-developpers] [sympa-commits] sympa[9263] branches/sympa-6.2-branch/src: [-dev] Messagespool has its own constructor new(),
Guillaume Rousse, 05/24/2013
- Re: [sympa-developpers] [sympa-commits] sympa[9263] branches/sympa-6.2-branch/src: [-dev] Messagespool has its own constructor new(), Marc Chantreux, 05/24/2013
-
Re: [sympa-developpers] [sympa-commits] sympa[9263] branches/sympa-6.2-branch/src: [-dev] Messagespool has its own constructor new(),
Guillaume Rousse, 05/24/2013
-
Message not available
-
Re: [sympa-developpers] [sympa-commits] sympa[9263] branches/sympa-6.2-branch/src: [-dev] Messagespool has its own constructor new(),
Guillaume Rousse, 05/23/2013
- [sympa-developpers] Refatroing spool classes was Re: [sympa-commits] sympa[9263] branches/sympa-6.2-branch/src: [-dev] Messagespool has its own constructor new(), IKEDA Soji, 05/28/2013
-
Re: [sympa-developpers] [sympa-commits] sympa[9263] branches/sympa-6.2-branch/src: [-dev] Messagespool has its own constructor new(),
IKEDA Soji, 05/23/2013
Archive powered by MHonArc 2.6.19+.