Developers of Sympa

[Guillaume Rousse <address@concealed>]

Le 11/07/2013 11:27, David Verdin a écrit :
> What do you think of all this?
Well, before discussing which method is needed exactly, what should they 
do, and how should they be implemented, I'd prefer first to discuss the 
number of classes we need, their names, and their exact relationship, as 
previously discussed with Soji and Marc here. And given the recurrent 
usage of IAmASympaClassButMyNameIsLongersThanYours as package name, it's 
not really self-explaining :)

The first point IMHO should be: should we support both File and 
SQL-based spools, and let user configure it at usage time ?

The second point is: do we really need different classes for storing 
different kind of content, and for how many different content types 
exactly ?

If the answer to both question is 'no', it means a single Sympa::Spool 
class is enough. That's scenario A.

If the answer to any of those question is 'no', it means we just have to 
represent a single specialisation hierarchy, which is quite simple too. 
That's scenario B, with two different variants:
- B1: Sympa::Spool::File and Sympa::Spool::SQL
- B2: Sympa::Spool::Task, Sympa::Spool::Message, Sympa::Spool::Key, ...

If the answer to both questions is 'yes', it means we have to represent 
two different specialisation hierarchies, wich is a bit more complex to 
represent, but still possible. That's scenario C, with even more 
different variants.

Personnaly, I'm still not persuaded the added modelisation complexity of 
scenario C is really needed, and I'm a big fan of scenario B1. For me, 
spool object, as any other basic objects such as locks, data source, 
etc..., should focus on low-level spooling primitives (storing, 
extracting), and not invest too much on content-specific logic, that 
should be handled somewhere else.

For instance, searching if a list subscription is already registered in 
spool does not mandate to have a dedicated method in the spool class. A 
dedicated function, in an helper module Tools::Spool if called from 
different parts of the code, taking a spool object as parameter, may 
achieve exactly the same result.


Additional nomenclatural advices
- always prefer explicit name or vocabulary or historical sympa slang: 
'file spool' is better self-explanatory than 'classic spool'
- don't concatenate names, but use hierarchical nature of perl 
namespaces to represent a specialisation hierarchy: Sympa::Spool, 
Sympa::Spool::Key and Sympa::Spool::Message is more explicit about their 
relationship
--
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