On Thursday, 26 June 2014 16:01:55 CEST, Karan Luthra wrote:
1. I have proposed implementing the SMTP client using Qt's state machine framework, for the SMTP interaction is very well modelled as a finite state machine.

I do not recommend using Qt's state machine for this as it seems to be rather tightly knit with the GUI's needs. In particular, features like property animation, state saving etc make little sense when one implements an internet protocol. IOW, the state management can probably be done with a single enum. I don't think that using the Qt's state machine thing would bring any simplification or other benefits compared to that.

Another important bit is command pipelining (not mandatory in SMTP, but possible and should be supported anyway).

Jan suggested TDD when the proposal was written and I read articles about this practise and I am very excited to go the TDD way.

Yes, that's one possibility. Don't overdo it -- when your component is still not designed (i.e. you don't know how exactly it's going to look like, when it is going to send some commands, etc), it would be a mistake to write all the tests in advance IMHO. Especially when one doesn't even have the public API finalised.

Now to get even the basic thing started, there are two tasks: A) Treat the qwwsmtpclient as a blackbox, and make it use Streams::IODeviceSocket::readLine() instead of its own instance of QSslSocket's readLine().

That would mean modifying the qwwsmtpclient just for the sake of testing. I'm not sure that it's worth the effort, given that you intend to replace that library anyway.

Furthermore, we don't know yet that the behavior of qwwsmtpclient is the optimal one. An example is command pipelining. I don't know from the top of my head whether it's supported already. If yes, cool, if not, be sure that the replacement can do it -- it saves time when sending e-mails.

And, B) Treat the SMTP client as a white box, and replace the internal logic with a totally new design -- the one implemented with Qt's state machine classes.

There is no need to follow the qwwsmtpclient's public API. Just look at Trojita's AbstractMSA and see what API matches its requirements. Yes, there will probably be some sendMail(recipients, data) and sendMailBurl(...) methods, but there's no pre-existing reason for closely modeling the qwwsmtpclient's public interface.

have something working by the time it's end of two weeks.

This is going to be a lot of work, so to prevent a future disappointment, I don't think you'll have it ready in two weeks time.

[1] rfc5321 (SMTP)

Also be sure to check all the (E)SMTP extensions. See http://tools.ietf.org/html/rfc5321#section-8 for details.

Cheers,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

Reply via email to