fwaggle/lazy-temp-chans original

## lazy-temp-chans original
Split my pull request to only deal with the first half of this glorious plan, because the second half is ripe with logical issues that need fixing. I decided to retain the original proposal text though, in case I wanted to know what I was smoking at the time.

Here it is:

I'd like some feedback on this idea please. :D

Basically I'm tracking the timestamp since each channel was last used, accessible via Ice*. This first feature allows not only the second, but it also allows server admins to do things like find channels that haven't been used in ages and remove them from the tree.

The second feature allows a server admin to set temporary channels to hang around a bit after the last user leaves. It sounds cracked out, but hear me out. On my public servers I've got some really faithful groups who come back day after day and set up their channels again... obviously from a commercial host standpoint I'd prefer to convert these people into paying clients, but I'm not too fussed - it's just awesome they're using Mumble.

So the idea is that on my public servers I could setup temporary channels to hang around for say, one day. If the users get disconnected or whatever, their temporary channel is still there and they can rejoin it when they get back. If they come back every day, their ACLs and everything stay put and their channel is semi-permanent. If they stop using it, the server automatically prunes it.

The only issue I can conceive of is someone going through and making a boatload of temporary channels and leaving each one in the tree... I'm not sure how to solve that one - another threshold which is the minimum amount of time the channel must exist for it to remain sticky?

Anyway, even if it's not something that'd make it into the main Mumble tree, I'd really like some feedback on it (and I can separate the first half if it's only the second half that's deemed stupid).

* I'm thinking maybe the Ice response shouldn't be the time-since-epoch, but just how many seconds since it was last used. The reason is because any form of clock desync, or disagreement over timezones, could lead to misleading results.
	Split my pull request to only deal with the first half of this glorious plan, because the second half is ripe with logical issues that need fixing. I decided to retain the original proposal text though, in case I wanted to know what I was smoking at the time.

	Here it is:

	I'd like some feedback on this idea please. :D

	Basically I'm tracking the timestamp since each channel was last used, accessible via Ice*. This first feature allows not only the second, but it also allows server admins to do things like find channels that haven't been used in ages and remove them from the tree.

	The second feature allows a server admin to set temporary channels to hang around a bit after the last user leaves. It sounds cracked out, but hear me out. On my public servers I've got some really faithful groups who come back day after day and set up their channels again... obviously from a commercial host standpoint I'd prefer to convert these people into paying clients, but I'm not too fussed - it's just awesome they're using Mumble.

	So the idea is that on my public servers I could setup temporary channels to hang around for say, one day. If the users get disconnected or whatever, their temporary channel is still there and they can rejoin it when they get back. If they come back every day, their ACLs and everything stay put and their channel is semi-permanent. If they stop using it, the server automatically prunes it.

	The only issue I can conceive of is someone going through and making a boatload of temporary channels and leaving each one in the tree... I'm not sure how to solve that one - another threshold which is the minimum amount of time the channel must exist for it to remain sticky?

	Anyway, even if it's not something that'd make it into the main Mumble tree, I'd really like some feedback on it (and I can separate the first half if it's only the second half that's deemed stupid).

	* I'm thinking maybe the Ice response shouldn't be the time-since-epoch, but just how many seconds since it was last used. The reason is because any form of clock desync, or disagreement over timezones, could lead to misleading results.