On Fri, 2009-10-16 at 16:52 +0100, Ed W wrote:
What I meant is what happens in most places where I plug in ethernet cable while a wireless connection is already there: I get a new IP for the wired connection. Then I have two IPs. Only one of the interfaces is the default gateway. But there's nothing special going on, all connections use their original local IP regardless of how the default gateway is changed. If you kill one of the interfaces, all of its conncetions will drop.
Hmm, I haven't tested whether this is what actually happens on some unix'y OS, but I will take your word for it.
At least OS X does that.
However, in the case above I'm not sure I understand your original point?
I'm not really sure anymore what anyone's point is :)
Yes, the user+ip syncing is important. But I don't see any point in adding the +ip part, since user-only syncing is just as good for most people and better for a few others.
Well, I'm not going to over-argue the point, but right now I personally have both a desktop AND a mobile device (and expect this to be a common situation for most users with a mobile device), so in my case I prefer to have the mobile device talking as little as possible, and to distinguish the two devices we probably need to use something like IP as a proxy (not perfect of course because both could be behind the same NAT...)
But even if you distinguish them, how would you treat them differently? Are you thinking about using different imap_idle_notify_interval values? But how would Dovecot know what type of device is there? I guess if you hard code some IP ranges as "mobile" that could work. But even in that case it doesn't make a difference that the syncing is done only per-user.
P.S. I posted some notes on zlib some time back - what kind of things could I do to increase the chance you might investigate supporting the COMPRESS extension in the near future? Obviously writing the code would be one option -
The only option for now.. Implementing it myself isn't really a priority.
would you perhaps mind pointing me towards the obvious spots to look at to do such an integration? I'm quite keen to give it a whirl because the Profimail guys very kindly implemented it recently and I'm hoping to see the new Thunderbird released sometime (in the next few years?) soon...!
The important part is to get zlib istream and ostreams implemented. The easiest part is to start with is by converting current zlib plugin from using gz*() functions reading files to reading the input from istream and converting it internally then in memory. So basically change it to work with:
struct istream *i_stream_create_zlib(struct istream *input);
There are several istream*.c files implementing various filters already, as well as the istream-zlib.c itself. It probably wouldn't be too difficult to do it.
For ostreams there aren't much examples. Dovecot v2.0 code tree has ostream-buffer.c. Also a month or so ago I implemented ssl-iostreams but decided not to commit them to 2.0 tree, at least not yet. I put them now to http://hg.dovecot.org/dovecot-2.0-sslstream/