El dc 14 de 05 del 2008 a les 13:00 -0300, en/na Francisco Tufró va
escriure:
> On Wed, May 14, 2008 at 11:45 AM, Pau Arumí <[EMAIL PROTECTED]>
> 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@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.
Yes.
>
>
>
> 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?
many outs -> 1 in, is (should be) supported, yes.
A test for this? Mmmm... i don't see the need, because the feature comes
free, i mean: IMO, there's is no new code associated to this feature.
But add the test anyway, if you feel like.
Pau
>
>
>
>
> 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ó
> <[EMAIL PROTECTED]>
> > 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
> >
>
>
>
_______________________________________________
Clam-devel mailing list
Clam-devel@llistes.projectes.lafarga.org
https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
