@x-lette: as you said, if you're browsing the web or doing any other network operation that requires user input, you'd have the connection dropping constantly -- either that or, even with your proposed system, you'd have to set the limit so low that it'd actually take zero activity to have autodisconnect close the connection. In my experience, if there's an active connection on and you either have network-bound widgets on the dashboard and/or apps in the background that fetch data from the net, you'll always get some activity.

It's tricky getting something like this right. For automated retrieval of information, your idea would work great. But for all those times when you're actually doing something yourself, it'd be tricky configuring it so it wouldn't trip you up at every turn.

I'd propose the following that, despite not being perfect and coming with its own drawbacks, would serve to alleviate most people's problems with the intervals -- let us have 2 interval settings for connection checking, each with its own bandwidth limit:

a) an "Initial" grace period, and associated traffic threshold, that you could set to a higher limit (which you'd then tailor to match the typical usage time and bandwidth of your automated retrieval apps/widgets/push-email .. say 3 minutes and a total of 120 KB, or 40KB/min for x-lette's example)

b) the interval at which autodisconnect would check the connection status and traffic after that initial period, which you'd tailor to more human-involved tasks, like performing updates, browsing the web, etc.

Either that or allow a "special" setting to be enabled that would allow you to configure something like "monitor traffic every minute for an initial period of X minutes and as soon as a single minute goes by where traffic fell below a certain threshold Y, close connection" -- for automated tasks that take less than those X minutes to complete where you're guaranteed to have Z/min traffic, you'd set Y to be very close to Z resulting in a closed connection pretty much as soon as the automated tasks completed.

If, however, in addition to the automated tasks, you're also doing something else (like browsing the web or replying to emails, whatever) that extra traffic would keep the connection alive and if the session were to extend beyond the initial period of X minutes, the "normal" threshold and interval would kick in and you could set these to be a bit more lax (say, by having a bigger interval or a lower threshold) which would help to keep the connection alive for those human-input sessions.

Did I make it too confusing?

For any of these two "systems", or even the way the app works right now, I'd suggest people put autodisconnect into "testing mode" by setting the interval(s) to 1 minute and using a very low threshold (say 1B/min, yes BYTE .. this will result in the connection being kept alive for the tests) and then do a "tail -f /var/log/autodisconnect.log" so you can gauge how much is being received every minute. That'd allow people to really tailor the intervals to their usage/needs.