Bringing this up again: Auto-update & Graceful degrade?

[thantik]

I've run into this in the past. Not lately, but I have. And I thought about it so I'm bringing it up again.

In your implementation of the communication protocol, is there any way you could upon connect, specify what "features" the server has available and enable/disable those features on the client for a 'graceful downgrade'? (Maybe also specify a protocol version?)

I ask, because on top of that it would be cool to auto-update client versions like google chrome does. (Download in the background in a staggered-release fashon, store the EXE, then replace it upon application close so when the user opens up the next time, they are on the new version)

Both of these features together would allow graceful upgrading, while allowing the user to use whatever version he wants (My problem is that I've had issues with people being too lazy to update the client software.)

In the reverse, this could allow the server software to be upgraded, without worrying about the client needing to (Of course this means every time a major communications change is put in place, you'll need a 'downgrade' copy so that the server can communicate with the old client.)

I know it would probably be a painful overhaul to do now, but maybe keep these suggestions in mind for later while building new code? That way as you fix one thing, or overwrite some old code with a new function, you can incorporate the changes slowly allowing for a full switch over later.

[ChrisW]

Auto-updating is something that I might implement at some point. I don't feel like it's a very big deal since I try to keep things forward and backward compatible whenever possible and it's already incredibly easy to upgrade (download+overwrite). I don't think the users of VC are generally those that are computer illiterate, and this is a perfectly acceptable process. Auto-updaters are also notoriously insecure. First, you resolve a hostname (not secure), download executable code, then automatically execute the code which involves changing the contents of your hard disk. I for one am more comfortable with a notice that an update exists with a link to the new version. At least that way you can keep an eye on the URL and have the chance to verify the contents of the download.

Graceful downgrading sort of goes on already in that features not supported by the server simply won't work, but you'll still be able to connect to the server normally. Perhaps those features could be grayed out instead - you're right about that.

[thantik]

On auto-update couldn't you check an MD5 hash of the executable with server, website + 1 other client? It would provide 3 sources of verification, although all based on information from the website. (Domain hijackings aren't all that uncommon either I guess) -- or maybe verification through a second website (sourceforge?)? I guess it would require more work to release a new version though, as the MD5 would need to be posted at least 2 places.

Even just an alert saying there is a new version available would be a step forward. I honestly didn't know how much effort you took into making things stayed compatible, the suggestion was purely generic. It's good to know that you already do this though.