[Dovecot] v2.0.alpha1 released

[Timo Sirainen]

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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20091016/78c2ae9d/attachment.bin