Developers of Sympa

[David Verdin <address@concealed>]

Le 11/07/13 17:09, Guillaume Rousse a écrit :

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

:-P
I must have written too much java in my life...

address@concealed">
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.

First of all: I love the way you named these modules. it's so much clearer than how I would have done it.
Next time I create a module, i'll make sure to write to the list for organization / naming advice.

Now my vote goes to B2 and B1. both. :-D
I explain.
We need to maintain both filesystem and SQL spools because we want to maintain bulk.pl on the filesystem. This mechanism works well since several years now, so I see no reason to get rid of it.
B1 could then do the trick.

But...

We want to maintain a certain level of capability to query files from the spools. That means we need informations from these files. We obtain them through two mechanisms:
1- parse the file name
2- parse the file content

For subscription requests, for example, the name of the subscription sender, as well as his gecos and custom attributes are locate in the file content, not its name.
That means that we need to parse the file content if we want to search subscription requests from a praticular address.

That's why I want to have different classes for different spools: they don't deal with the files waiting in spool exactly the same way, and I thought we could use subclasses to handle this disparity.

So we could have that kind of hierarchy:

Sympa::Spool::SQL
Sympa::Spool::File::Task Sympa::Spool::File::Message Sympa::Spool::File::Key etc.

Back to you!

Cheers,

David

address@concealed">

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

--
A bug in Sympa? Quick! To the bug tracker!

David Verdin Infrastructure pour les Services Informatiques
Tél : +33 2 23 23 69 71 Fax : +33 2 23 23 71 21   www.renater.fr	RENATER 263 Avenue du Gal Leclerc 35042 Rennes Cedex

Attachment: smime.p7s
Description: Signature cryptographique S/MIME