Developers of Sympa

[IKEDA Soji <address@concealed>]

Attached is incomplete draft of my proposal.
I don't wish to discuss on this right now.

Regards,

--- Soji

On Tue, 17 Jun 2014 10:08:22 +0900
IKEDA Soji <address@concealed> wrote:

> Hi,
> 
> On Mon, 16 Jun 2014 16:04:23 +0200
> Guillaume Rousse <address@concealed> wrote:
> 
> > Le 06/06/2014 17:04, IKEDA Soji a écrit :
> > > I suppose the problem you are struggling is caused because required
> > > modules are not explicitly specified in the source, not because
> > > they are not practically loaded.
> > No, the problem I'm struggling with is the lack of modularity in current 
> > code base, and too much coupling between components.
> 
> I'm planning to make a proposal on refactoring about Message, spools
> and "pipeline".  I believe it also will solve dependency loop.
> 
> I'll make it after the release of 6.2b.1.
> 
> > >>> I think the situation is same on task instruction.  When the task is
> > >>> running, is it possible that the module like Sympa::List has not been
> > >>> loaded?
> > >> t/instruction.t, for instance.
> > >
> > > Well, required use lines should be added.
> > There is no need of a list object just for testing instruction parsing.
> 
> Regards,
> 
> --- Soji
> 
> -- 
> 株式会社 コンバージョン  セキュリティ&OSSソリューション部   池田荘児
> 〒231-0004　神奈川県横浜市中区元浜町3-21-2 ヘリオス関内ビル7F
> e-mail address@concealed  TEL 045-640-3550
> http://www.conversion.co.jp/


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

Draft proposal on message, spool and pipeline
=============================================

Here is a pseudo-UML to describe my proposal.

For example, sympa.pl may be concidered as a "pipeline" to fetch each
message from _msg spool_ and at last store it into _bulk spool_.

 sympa.pl
   | run()
   V
+------------------------------------------+
| Pipeline::Incoming                       |
|------------------------------------------|
| +run()                                   |
+------------------------------------------+
  | kick     ^ message obj.    | altered message obj.
  V next()   |                 |
+----------------+            +----------------+
| Spool::Message |            | Spool::Bulk    |
|----------------|            |----------------|
| +next()    :   |            | +store()       |
+----------------+            +----------------+
 | metadata  |    \            |             ^   \
 | content   |     \           |  serialized |    \
 V           |   msg spool     V  message    |    bulk spool
+-------------+      ^        +---------------+       :
| Message     |      |        | Message       |       V
|-------------|   queue.c     |---------------|   (processed by
| +metadata   |      :        | +metadata     |   Pipeline::Outgoing
| +content    |  (injected by | +content      |   under bulk.pl)
|-------------|  MDA)         |---------------|
| +new()      |               | +to_string()  |
+-------------+               +---------------+
 |metadata ^
 |         |
 V         | context

/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\
+-------------+    +--------+    +--------+
| Site        |    | Robot  |    | List   |
|-------------| or |--------| or |--------|
| +instance() |    | +new() |    | +new() |
+-------------+    +--------+    +--------+


* Metadata

The information following each message.  On filesystem spool, it is
typically encoded into file names.  E.g. a file name
  address@concealed
encodes the metadata
  {
      localpart => 'listname',
      listtype   => 'return_path',
      domainpart => 'domain.name',
      time       => 143599229,
  }

Note: To search or fetch specific message from the spool, only
metadata can be used as key of query.  Because content of message
has not already read nor decoded.

* Context

Metadata always includes information of context: List, Robot
or Site.  For example,
- Incoming post to <address@concealed> has List context.
- Incoming command message to <address@concealed> has Robot
  context.
- Message sent to super-listmaster has Site context.

Context is determined when Message is instantiated and never
changed through its lifetime.  In other words, each message
"knows" context of its own.

Note also: This architecture is free from dependency loop about
object definition.


(This proposal is incomplete.)

====================================================================