Developers of Sympa

[David Verdin <address@concealed>]

Le 12/07/13 05:27, IKEDA Soji a écrit :

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.

LDAP ? Now that's something I never heard of before.
But why not? Once we've refactored the code for SQL and filesystem, it should be "easy".

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?

Yes, completely.
Actually, that's an idea I had, but i could not sum it up correctly yesterday, so I just skipped it fomr my answer.
But it looks logical that as well as we have spool objects, we should spool element objects;

However, I wonder whether we should not have dedicated spool objects as well. Otherwise, how will we be abl to link a particular spool to a particular spoole element (i.e., how will we be able to say that the subscribe spool shall store its content into subscription object)?

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.

Well, here is a proposal I made to Marc and Guillaume when I met them a few weeks ago. by looking at the history of discussion on this list, I forgot to inform you of this discussion; For this, I apologize.

As we are far past the delay I had in mind for releasing the 6.2, I propose that we don't release the 6.2.
instead, we will continue our refocatoring over the summer and relase a 7.0 with the new code base in September / October.

The advantage of this is that we won't have to support a code base that we already now is doomed to disappear, letting us concentrate on code improvments.
Also, once I'm done rolling back to filesystem spools, I'll merge the current branches and put all that on git. That will be the basis for development of the 7.0. In that context, not releasing the 6.2 will prevent having to handle frequent merges between SVN and git.

So that's roughly the plan I had in mind.

Before merging, I want to be able to make all the spools work on the filesystem. That way, I'll know if troubles come from the merges or from the current code.

Do you agree with this plan of action?

Regards,

David

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