Skip to Content.
Sympa Menu

devel - Re: [sympa-developpers] Proposal on refactoring about message, spool and pipeline

Subject: Developers of Sympa

List archive

Chronological Thread  
  • From: IKEDA Soji <address@concealed>
  • To: address@concealed
  • Subject: Re: [sympa-developpers] Proposal on refactoring about message, spool and pipeline
  • Date: Fri, 4 Jul 2014 13:20:49 +0900

Guillaume and all,

On Thu, 03 Jul 2014 17:58:24 +0200
Guillaume Rousse <address@concealed> wrote:

> Le 30/06/2014 05:02, IKEDA Soji a écrit :
> > Hi developers,
> >
> > I planned to make this proposal after release of 6.2b.1. However,
> > recently I feel there aren't sufficient mutual-understanding on
> > coming development. So I make proposal for now.
> >
> > Especially Guillaume and David, I want your comments and suggestions
> > to my proposal. I believe it will help to make discussion among us
> > more or less smooth.
> I like the Pipeline idea, it should introduce a intermediate level
> between the executable and the various objects they manipulate.
>
> I'm less convinced by the context tracking issue.
>
> Basically, I'm not really sure a message should keep itself a constant
> link toward its context. In most case, that's just to access
> configuration parameter that could be passed directly by the method
> invocator.
>
> For instance, when checking DKIM status, checking tham DKIM status is
> actually required could be done by the caller, rather than embedding
> this check in the object itself:
> $message->get_dkim_status if $robot->dkim_feature eq 'on';
>
> But this suppose than the caller has another way to identify the message
> context than retrieving it from the message object, and I lack proper
> knowledge of sympa internal to ensure it is always true. So let's forget
> about it.

I don't stick to idea that context would be included into object
much. In my idea, code will become

$message->get_dkim_status if $message->context->dkim_feature eq 'on';

There is not remarkable difference. And anyway, context will be
refered only from inside of functions in Pipeline.


> However, I'm quite sure than keeping this link as a permanent reference
> to full blown Sympa::List or Sympa::Robot objects has drawbacks.
>
> First, it create a dependency from the Spool classes to those
> Sympa::List and Sympa::Robot classes, because every time a message is
> deserialized, those references are established immediatly, even if they
> aren't used thereafter.
>
> Second, it creates references between objets, and David already told me
> about heavy memory usage issues probably caused by circular dependencies
> between objects preventing them to be freed by the garbage collector.
>
> So I'd rather favor a lazy initialisation model:
> - when a message object is deserialized, it only retains a list ID or a
> robot ID
> - when the context is accessed from the message objet, because it is
> actually used, this identifier is converted to an object
>
> That's transparent for the caller side, and leverage both issues.

My proposal was a bit illegible. In the figures,

[Pipeline::XXX]
|
|use
v
[Spool::XXX]
| |
|use |use
v v
context object
[List/Robot/Site] [Message/Task/etc.]

Dependency loop seems not to occur.

- Object packages (Message etc.) need not use'ing context package,
because latter have already been instantiated by Spool.

- Context packages (List etc.) need not use'ing object, spool nor
pipeline packages, because functions require them have been moved
to Pipeline package.

And it seems not possible that Pipeline never access to context
of each message: E.g. when a message is related to a list, pipeline
must access property (config parameter etc.) of that list.

Am I right?

> ie, something as:
>
> sub get_list {
> my ($self) = @_;
>
> if (!$self->{list}) {
> require Sympa::List;
> $self->{list} = Sympa::List->new($self->{list_id};
> }
>
> return $self->{list};
> }

I suppose this is a method of Message class. As described above,
$self->{list} (or $self->{context}) is guaranteed to be assigned at
the time of instantiation.

sub get_list {
my ($self) = @_;
return $self->{list};
}


Regards,

--- Soji

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



Archive powered by MHonArc 2.6.19+.

Top of Page