Developers of Sympa

[IKEDA Soji <address@concealed>]

David,

On Fri, 12 Jul 2013 14:32:56 +0200
David Verdin <address@concealed> wrote:

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

Spool element (Message, Task, ...) would have an attribute keeping
the spool object from which they were picked out.

Additinally, It seems that the element objects would keep several
levels of "metadata":

  (a) Spool.
  (b) Metadata given by spool, not using content:
    - Taken from column values by SQL spool.
    - Taken from parts of file names by filesystem spool.
    (b1) Context - mandatory
      - List object, Robot object or none (global).
      - messagekey.
    (b2) Other metadata - optional by content types
      - priority, date, authkey, task model, ...
  (c) Metadata given by content:
    - Data given by X-Sympa-* headers,
    - Sender, envelope-sender,
    - DKIM validity,
    - etc.
  (d) Content itself.

I believe spool methods would be able to handle metadata (a) and (b)
(particularly, filesystem spool can handle limited kinds of metadata),
while they would not be able to handle (c) and (d).

That's why $spool->get_content(...) couldn't filter subscription
requests by the sender.  Such filtering might be done on the
outside of spool package.

                              *

I'll respond remainder of your message later.

Regards,

--- Soji


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