Developers of Sympa

[IKEDA Soji <address@concealed>]

Hi fellows,

On Thu, 11 Jul 2013 17:09:45 +0200
Guillaume Rousse <address@concealed> wrote:

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

I'll answer "Yes", and more: Key-value store, LDAP (a colleague of
my company asked me of possibility) and so on.

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

I'll answer "Yes".  Sympa uses several kind of content: Message,
bounce, message digest, task, and maybe request...

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

- C: Sympa::Spool::File and Sympa::Spool::SQL, and
  Sympa::Message, Sympa::Message::Held, Sympa::MessageDigest, Sympa::Task, ...

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

In scenario C, each content object MUST have common interfaces:
serialize(), new() (and maybe load()) for interaction with spools.
And, MAY have interfaces specific to each content: validating messages,
run tasks etc.

I suppose that there are no need of scenario B2 defining spool
subclasses specific to each content object, and that scenario B1
is a part of scenario C.

Is my understanding correct or not?


> 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

I have agreed to your naming convention and hope it to be realized soon.
Git will handle such reorganization much better.



BTW: Rainy season, the season of hydrangea, has end in Tokyo.
Summer is come.  Would we be better to release Sympa 6.2 faster,
or be better to get well-factored codebase?  ...I cannot decide.

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