Developers of Sympa

[Guillaume Rousse <address@concealed>]

Le 23/05/2013 11:58, IKEDA Soji a écrit :
> Guillaume,
>
> On Thu, 23 May 2013 11:01:20 +0200
> Guillaume Rousse <address@concealed> wrote:
>
> > Le 21/05/2013 16:05, address@concealed a écrit :
> > > --- branches/sympa-6.2-branch/src/lib/Messagespool.pm   2013-05-21 13:56:37 
> > > UTC (rev 9262)
> > > +++ branches/sympa-6.2-branch/src/lib/Messagespool.pm   2013-05-21 14:05:40 
> > > UTC (rev 9263)
> > > @@ -26,6 +26,14 @@
> > >
> > >    our @ISA = qw(SympaspoolClassic);
> > The names used for those classes doesn't bring any hint about this
> > relationship, and one has to dig in the code to understand it.
> >
> > I'd rather suggest:
> > SympaSpool for the base class
> > SympaSpool::Message for the child class
> >
> > And if SympaspoolClassic is meant to be a file-based implementation,
> > this inheritance tree could be even more explicit:
> > SympaSpool for the base spool class
> > SympaSpool::File for the file-based spool class
> > SympaSpool::File::Message for the file-based message spool class
> >
> > Of course, the 'Sympa' prefix could also be replaced by a Sympa
> > namespace, as done in the cleanup branch, but that's secondary.
>
> I agree with you on naming convention.  My idea is:
>
> - SympaspoolClassic => Sympa::SpoolFile
> - Sympaspool        => Sympa::SpoolSDM
Avoid name concatenation whenever possible:
- Sympa::Spool::File
- Sympa::Spool::SDM

Also, 'SDM' is pure sympa slang, and susceptible to disappear. I think 
Sympa::Spool::SQL would be more appropriate.

> - Messagespool      => Sympa::Spool::Msg
I prefer explicit names over abbrevation: Sympa::Spool::Message

> - KeySpool          => Sympa::Spool::Mod
'Key' seems more explicit than 'Mod', but I'm not sure what it is 
supposed to be in both cases :)

> - TaskSpool         => Sympa::Spool::Task (?)

> The first two seem to be sibling classes.  Any of child classes
> can switch their base in the future.
I don't think backend implementation (file/SQL) should be hard-coded, if 
they are multiple one availables. I'd rather make it a configuration 
option, and let final user decide which one to use.

Basically we have to represent two distinct classifications here:
- backend type
- content type
I'd keep the first one in a specific Sympa::Spool::Backend tree, and use 
either multiple inheritance or composition to achieve the various 
combinations.

Multiple inheritance solution:
Sympa::Spool::Message::File =
  Sympa::Spool::Message +
  Sympa::Spool::Backend::File

Composition solution:
A single Sympa::Spool::Message class, with a Sympa::Spool::Backend 
attribute.

> In addition, I'm considering a few more classes (in these weeks I'm
> working offline to refactor codes on interaction between Message object
> and spools):
>
>    for 'automatic'      Sympa::Spool::Automatic
>    for 'bounce'         Sympa::Spool::Bounce
>    for 'digest'         Sympa::Spool::Digest
>
> How is this?
I lack enough knowledge of what you are trying to achieve here. But I'm 
effraid than if 'Sympa::Spool::Message' means 'a spool containing 
messages', 'Sympa::Spool::Automatic' doesn't has an equivalent 
semantics. 'Sympa::Spool::Backend', as I suggested earlier, doesn't 
either, tough...

AFAIK, digest and bounce are just specific kind of messages, so if 
specific code is really needed there, I'd rather have them implemented 
as Sympa::Spool::Message subclasses.

--
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