Including an IMAP server

[xarg]

There is IMAP server implementation here (still very much WIP): https://github.com/alienscience/imapsrv

It's not functional yet, but there is a lot of enthusiasm of making this server work and collaborations are slowly coming in. I also use go-imap. So I thought: Wouldn't it be convenient to have both the client and the server in the same repo or package? A heterogenous API for both the client and the server would be very nice for people looking for an imap implementation in golang.

Another advantage would be: testing! Instead of using a mock (the case now), it would be nicer to bootstrap a server that listens on a real port and do the testing.

Not to say that there will be more people testing out/contributing to the client/server.

Before opening up this issue I talked to the author of the server and he is not opposed to the idea of merging, but doesn't have the time to do it. I do have the time though.

What do you think? Can we work together?

[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.