Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add auto-update ability for all platforms #50

Open
einsteinx2 opened this issue May 9, 2013 · 8 comments
Open

Add auto-update ability for all platforms #50

einsteinx2 opened this issue May 9, 2013 · 8 comments
Assignees
Milestone

Comments

@einsteinx2
Copy link
Owner

We looked into possible solutions, and it looks like a home built one is going to be best. The basic idea is as follows:

All platforms:

WaveBox core checks for updates from our server periodically. When an update is available, this data is saved. The update alert is shown to users in web/mobile clients.

Windows and Mac:

When a user selects to update, WaveBox downloads the installer file and runs it. User must follow the prompts to complete install.

Linux:

When user selects to update, they are directed to the download page for installers so they can choose the best one for their system.


In the future:

In place auto-updating with no user interaction.

@ghost ghost assigned einsteinx2 May 9, 2013
@mdlayher
Copy link
Contributor

I'm not sure what your plans are for implementing the update server, but I think it could be neat and resource efficient to use BitTorrent via MonoTorrent (https://github.com/mono/monotorrent) to distribute updates to users. That way, WaveBox users can download updates from other WaveBox users, and put less stress on a central server.

@einsteinx2
Copy link
Owner Author

BitTorrent is definitely a good idea. I've also been thinking git, but that would be more centralized, and I agree that BitTorrent will reduce bandwidth costs. We would have to make sure it's highly limited in bandwidth usage and has a way for users to opt out. Also we would need to be seeding all updates ourselves.

I've finished the initial AutoUpdater class implementation. Currently it checks a url for json, which is an array of update infos. It can then determine if a new update is available. For beta 1, we'll just show an update alert to the user. But before release 1, we'll need full update capability.

Also, for updating the web interface, I'm thinking we use git for that (since it will be hosted for free on GitHub and the code in the repo will be the working code, no need for compiling -- we'll include compiled coffeescript to javascript in the repo with each commit).

Then what we'll need to do is include a file with each commit specifying the minimum WaveBox version that is supported. Then we can have WaveBox use GitSharp to pull the latest repo changes, check that file in the latest commit, and checkout the commit if the version is supported. That way we can keep the web interface updated without updating the whole application. We'll just have to test how to best update the web interface in place to have clients pick up on the change, or maybe that's not even an issue (i.e. web sites do it all the time)

@mdlayher
Copy link
Contributor

Justin and I both operate servers in house, so I'm sure we'd both gladly seed out releases of WaveBox. I bet we will also attract some other BitTorrent users who will gladly contribute their bandwidth as well.

I agree, git would be just fine for the web interface. We'd just need to make sure that it can cleanly merge code between releases, so users don't end up with a broken merge or something.

@einsteinx2
Copy link
Owner Author

Justin and I were talking over the use of bittorrent for updates, and he made a good point that Blizzard's bittorrent based updater was never great. The real problem is, you're not guaranteed which peers you'll connect to. So even if we have some fast seeds, your download speed could be very slow. Add to that the fact that bandwidth is extremely cheap, and we're thinking it's probably best to just throw the files up on S3 and be done with it. Or alternatively, S3 does support a torrent link for every S3 file (it's basically the S3 url + .torrent), which we can test to see how viable that is. But given port forwarding issues, random slow peer issues, etc, it may just be best to do a simple download.

@mdlayher
Copy link
Contributor

Fair enough if you're willing to sink some money into S3. I noticed a script was pulling from someone's personal Dropbox though, and that won't last long if a lot of people are using the application.

@einsteinx2
Copy link
Owner Author

Oh ya I think I'm reading a json file or something from my dropbox right now, but that's just for testing. For release we'll be using S3 likely for all downloads. We'll see what kind of money it ends up costing, and can find an alternative solution if necessary. In the meantime I'll pay for it out of pocket.

@einsteinx2
Copy link
Owner Author

After using the Xamarin tools for a while, I really like the way their auto-updater has the concept of "channels". So you can be in the Stable, Beta, or Alpha channels, and get the appropriate updates. That allows for anyone to easily participate in beta testing and switch back and forth at will.

If we could implement something like that, it would be great.

@einsteinx2
Copy link
Owner Author

And actually... since MonoDevelop (and probably Xamarin Studio) is open source, maybe we can look at their updater code and get an idea of what they're doing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants