[Clam-devel] Re: Problems with the list

[Francisco Tufró]

On Wed, May 14, 2008 at 11:45 AM, Pau Arumí <parumi at iua.upf.edu> wrote:

> Hola Francisco!
> could you send me a bounce to investigate the cause?

It was an smtp configuration problem:
[...]
Delivery to the following recipient failed permanently:

    clam-devel at llistes.projectes.lafarga.org

Technical details of permanent failure:
PERM_FAILURE: Gmail tried to deliver your message, but it was rejected by
the recipient domain. The error that the other server returned was: 550 550
relay not permitted. We recommend contacting the other email provider for
further information about the cause of this error. Thanks for your continued
support. (state 14)
[...]


>
>
> About the patch. I think it's good.
> Just two minor comments:
> We have the "imperative" methods (AddLink, RemoveLink) at the out
> control only --which i think it's reasonable-- then why not to simplify
> and have IsConnectedTo only to the out control as well? Sounds like
> duplicated interface to me.
> Agree?
>
> I guess (have not looked at it) the reason behind this decision is
> because it is how is done in current controls. If it is the case i
> wouldn't mind break the symetry. Or even refactor the current controls.


That's the reason, i just followed the current control tests and do it.
You are talking about IsConnectedTo only right?
Because if we remove isConnected or the mLinks member from the
TypedInControl we can't unlink it from the TypedOutControls when it's being
destroyed.
    template<class TypedControlData>
    TypedInControl<TypedControlData>::~TypedInControl()
    {
        while (!mLinks.empty())
            mLinks.front()->RemoveLink(*this);
    }

If you're talking just about the IsConnectedTo, i think it's ok.


>
> I prefer to wait to the next patch before commiting. Hopefully sending
> to the list works again.
>
> Also, the multiple relation (1 out -> many ins) is not tested.
> You could do a test like this:
> out --> in1
>    \-> in2
> then do out.SendControl(1)  and check it has been received in both
> inputs.

I'll do this test today.
Also yesterday i was thinking about the inverse case (many outs -> 1 in).
Should i do both tests? Or you think doing many outs -> 1 in is not correct?



>
> I think next tests should introduce the generic interface. For that, the
> trick is using base class references to concrete objects like this:
>
> TypedInControl<int> concreteIn;
> TypedOutControl<float> concreteOut:
> BaseTypedInControl & in = concreteIn;
> BaseTypedOutControl & out = concreteOut;
> ASSERT false, in.IsLinkable(out)

 Ok, when you commit the patch i'll send today, i'd start with this, I think
is a big patch and should be isolated from the above modifications.
Cambio y fuera.
Francisco


>
>
> Saludos!
> Pau
>
>
>
>
>
>
> El dt 13 de 05 del 2008 a les 12:52 -0300, en/na Francisco Tufró va
> escriure:
> > forgot the attach
> >
> > On Tue, May 13, 2008 at 12:45 PM, Francisco Tufró <nictuku at gmail.com>
> > wrote:
> >         Hi guys, I'm having problems sending messages to the list (and
> >         i haven't recieved any mail from it since sunday, and every
> >         mail i send bounces with a relay problem while i'm not doing
> >         relay), so i send the patch to you.
> >         I've done the "IsConnected, IsConnectedTo" tests and the
> >         Destructor tests (and all the implementation to pass them).
> >         So, please tell me what should i do next.
> >         :)
> >         Francisco
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20080514/478b1aa4/attachment.html>