Including an IMAP server about go-imap

[mxk]

I've been following that discussion on golang-nuts. Right now, I don't have much time to spend on a new project. You are welcome to take any code from the client and adapt it for the server, but I don't really see a benefit in combining the two. How often does an application need to be both?

For testing the client, you want to be absolutely certain that the server isn't doing something wrong. That's what the mock package gives you in a minimal amount of code. Why replace it by a real server and introduce the possibility of a client test failing because the server does something unexpected?

[xarg]

How often do you need an http client and a server in the same package? I'm talking about net/http of course. So the answer is: not very often, but when you do it kind of makes sense to have both in the same place and not look around. Also: code reuse.

On the subject of mocking, it's more philosophical I guess. Mocking is nice to have for doing fast and reproducible tests, but in a world were everything brakes all the time nothing can replace a real server that has to open sockets and has to use disk and memory, etc... I would very much prefer to test a library against that kind of a server (it can be a postfix in a docker image - doesn't really matter). A mock will give you a 'false' sense of security. This is just my opinion - a lot of people don't agree with me.

I suggest having both: mocking for fast tests and a reals server in a virtualbox somewhere to do the long tests with lots of stuff breaking left and right. Fabric (python) project uses this technique for example.

Since you guys don't have time for this I think I'll fork both projects and try to merge them. I need both, so it makes sense for me to do that.

[mxk]

You're right about code reuse, my only concern would be the introduction of many new dependencies that aren't necessary for the client. It's a question of how much functionality you want the server to have. I haven't thought much about it, but it seems to me that even a basic IMAP server would be more complex than a basic HTTP server. There is more state to keep track of and data storage is pretty much a requirement for IMAP, whereas HTTP can easily work with only dynamically generated content.

[xarg]

The server doesn't implement a storage on it's own. It offers interfaces for storage (sql, maildir, etc..), authentication.. The idea is that 3rd parties would implement maildir/sql/etc.. packages that comply to the mail storage interface. A la: http://golang.org/pkg/database/sql/

At least that is the plan at this moment.

The server itself could include some dummy storages to demonstrate the functionality, but it's beyond of it's scope to handle every possible mail store.

The implementation of even a basic server could be big and hairy, but I can't see why it would increase the complexity of the client.