Hi
- Wifi and Wired on Windows XP and earlier (possibly vista also?) - now XP does something clever, it appears to have connection tracking in place and once a connection is started on a given interface then that connection continues via the same interface even if the default gateway is changed, ie default gateway only affects new tcp connections and old connections are automatically routed through their initial net device. This allows you to do some funky stuff such as remote controlling a machine over a fast connection whilst getting it to connect to some dialup connection, you can continue to control the machine even after the dialup device is brought up, ie the remote control app doesn't suddenly switch to the new connection.
Do you mean those interfaces would have the same or different IPs?
Usually different IPs. But Windows does some clever connection state tracking and keeps data going out of the same interface as where the connection was first started from... I'm not sure how/why, but it's actually quite useful!
so I don't think it's actually possible to achieve the effect you described?
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.
However, in the case above I'm not sure I understand your original point?
I think the goal is still to minimise the number of times we bring an interface into life (for mobile devices), so if for example your two hypothetical devices were instead a wifi and 3G connection, then plugging in the second device will mean we have some connections out through wifi and some out through 3G, they might both well be imap connections to the same server and using the same username, but ideally we want to treat each bunch of connections separately (and minimise the number of times we use each interface)
Well, I would claim that it's only *important* to *synchronise* communications with a hash of username+IP (where IP is a proxy for communication interface in use on a given device). I can't immediately see the implications of syncing all communications with a given user, but I think it's possible to be more specific if this is useful?
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...)
I might be missing the point though, so I throw this up mainly as a data point...
How can I address this use-case? Perhaps in this case its better to use a single login and make the other accounts shared subfolders of that account? This isn't something I have tried so far though?
Shared folders would be better typically, I think..
I think this is something I will need to investigate further then...
The main problem is that it's hard to get any mobile devices with decent IDLE support and a decent folder implementation, expecting that app to ALSO be great at handling a nested folder of INBOX's scenario is going to be rather hit and miss... I will investigate Profimail on my N97 and see how it works (*excellent* app by the way - I don't mind plugging Profimail at all - better email app than most desktop programs!)
Cheers
Ed W
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 - 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...!