Implementing an auto updater/notifier?

[Christoph Hart]

Hmm not so sure about this. Of course the idea of everyone in this forum having their own installer that they just took from a template and slapped their logo on it sounds like a nightmare for the end user, but on the other hand I can imagine that there will be a lot of overhead trying to design a open source solution that works with multiple servers.

What are the downsides of including it in the plugin + having a manual option for people who dislike the plugin download path? The authorization + installation to the expansion folder is being done by the plugin but the user can choose whether he wants to download the samples automatically or if he wants to get a list of static download links to the .hr1 files?

[d.healey]

@Christoph-Hart said in Implementing an auto updater/notifier?:

What are the downsides of including it in the plugin

In a single plugin the downsides are minimal. However let's imagine 10 developers each release 10 plugins and one user buys all one hundred (don't laugh it could happen :p ). Now the user has to log in to 100 different plugins (and perhaps get them past their firewall). Each time they open their DAW template every instance is going to call up to a server to check for updates or do some DRM thing.

Each developer will come up with their own, slightly different, implementation of the downloader/installer. When a user disconnects from the internet all the plugins will react in a different way, some will be poorly implemented and popup with errors, others will crash the DAW.

Each of those 100 plugins will also need a separate installer, each one has to be built, codesigned, notarized, and maintained.

And the thing that got me considering this in the first place... a plugin should just do it's job, it shouldn't be a download manager or product catalogue.

My idea separates the download/installation process, reduces maintenance for developers and simplifies the install process for the user.

The main difficulty, as you pointed out, is making the system work with different server configurations. So we'd need to agree a standard, which is better than us all having a different standard. The system I proposed is fairly narrow in terms of what server configurations it will talk with, but there's no reason we couldn't expand it in the future.

[orange]

@d-healey I think one single "Downloader / Installer / License Manager" idea is very good and effective.

I've been using many many plugins of other companies. But I think Plugin Alliance Installation Manager is one of the best approaches. There is no need to discover America again. It has below features and it would be awesome if Hise made implementation has these features too:

• Directly downloads the plugins as zip files and extracts to the selected plugin locations. (No plugin installers requred anymore if you store the plugins as zip files on your server)

• So with this method, user can select the plugin formats that who needs. Well, no unnecessary server traffics anymore.

• Suitable for all kind of licenses such as: Single Products, Bundles, Subscriptions.

• It can activate or deactivate plugins/bundles/subscriptions individually. For example you have an All in One subscription package but at the same time a full perpetual license of a single plugin. So you decide to activate perpetual plugin license in Machine A. Or subscription licenses in Machine B....etc

• It has meta data fields that shows image and information about the single products / bundles.

• If a new plugin released, this software grabs the plugin and adds to the list automatically, which is an awesome feature also!

[d.healey]

That looks cool. Having unzipping has been suggested before by someone, I think in this context it could be very useful. It would even allow the download manager to handle non-HISE instruments, such as Kontakt patches or SFZ files - of course this would need to be implemented in HISE too and I think Christoph has enough work for now :)

[ustk]

zip management is already implemented in JUCE so wrapping an API shouldn't be too hard, well, however it is for me…

[d.healey]

@ustk said in Implementing an auto updater/notifier?:

zip management is already implemented in JUCE so wrapping an API shouldn't be too hard, well, however it is for me…

Well we can add that as a future upgrade :)

[d.healey]

This is kind of what I had in mind:

[d.healey]

I think I just realized a huge flaw in my idea. Expansions are encrypted with a unique key which is also used to decrypt and install them. Even if we could set the key via scripting I can't think of a way to transmit it from the server to the client securely... Might have to go with a per vendor solution after all and find other ways to mitigate the downsides

[orange]

@d-healey One template software. Per vendor can adjust and use it acording to their needs. I think there is no need to unify brands under one.

[d.healey]

@orange This is the current situation and the thing I wanted to avoid.

[d.healey]

Here's a possible solution, the download manager only does download managing and placing files in appropriate folders. Each plugin that uses expansions can check on startup a specific location for any newly added expansions and extract/install them.

This removes the need to transmit encryption keys and also means I could build the app with electron instead of HISE.

[Lindon]

@d-healey -- I see from your example graphics you've counted me in already ----as usual you have me completely-- I'm in in in in in.

[orange]

@d-healey said in Implementing an auto updater/notifier?:

@orange This is the current situation and the thing I wanted to avoid.

Why not making an app like your export tool that can be useful for everybody?

I mean you can implement a Downloader/Installer/License Manager app template with Hise and everybody can use it. Of course there should be some requirments that everybody should have (like wordpress or woocommerce...etc.). but it would be a total "in the box solution". And I am sure it will be a standart for almost every Hise developer.

So if the license handling is not included, the app definately would be deficient. One app that solves all of these ass pains and this app template will be used by everybody, then it will be a good money maker for you :) Totally in my opinion of course...

[d.healey]

@orange

Why not making an app like your export tool that can be useful for everybody?

That's kind of what I had in mind. I'd prefer it was a HISE app rather than an Electron or C++ app because it will give HISE developers (who don't know the other languages) direct control over the app. However because of the issues I've mentioned I think an Electron app will be the way to go.

This is a big undertaking so I'm going to put it on the back burner for now and just incorporate some kind of minimalist download/installer into my current project directly. When I have some free time I'll come back to this because I think it is ultimately what is needed both for users and developers.

[Christoph Hart]

As I see it there are multiple requirements that contradict each other here:

1. you want an open source solution. This prevents any kind of private key on the client side.
2. if you make one proprietary installer platform that is used by multiple companies it will increase the attraction of hackers and make it more likely that the private key of this single platform will be leaked (= exactly the reason why KONTAKTs copy protection scheme is worthless).
3. if everybody and his dog has their own installer chances are better that you stay below the radar of cracking crews, but the end user will hate it. At the moment it's already at the tipping point with one installer software for each "big" company, but if small indie developers with a portfolio of 1-2 products start shipping their installer it becomes ridiculous.

So if you want to avoid 3. and solve the problem 2, you will have to move any kind of encryption / authentication to the plugin (so the plugin itself has to be cracked instead of the platform). But then all that you are left with is a software that downloads a file to a location and you can simply resort to existing solutions (the best one for small devs would be Pulse at the moment) or make a simple open source app based on Electron if you don't want to offload that to a 3rd company. But then again, if everybody takes that template from you and just slaps his logo on the front, we're back at scenario 3...

[d.healey]

@Christoph-Hart said in Implementing an auto updater/notifier?:

1. you want an open source solution. This prevents any kind of private key on the client side.

The private key can still be in the compiled binary on the client side, it just can't be transmitted from the server. You can make an open source plugin without publishing the project.xml that contains the encryption key, no? --- And now I've finished reading your post and see you reached the same conclusion :)

if everybody takes that template from you and just slaps his logo on the front, we're back at scenario 3...

Yes this would be horrible. If I make an app it will be a single app for everyone (although people could take it as a template and build their own but hopefully they won't because that defeats the purpose). A template script for the HISE expansion installer side would be good, then people can drop that into their HISE projects.

[gorangrooves]

I am going to start with users downloading their product installers bundled with samples from their accounts on my website. It is a WooCommerce platform. If I see issues arise along the way, I would consider a dedicated downloader.

I have, however, built a fantastic download organizing tool (WP plugin) that allows customers to pick what they want to download. They see a single download button per product in their account and once they click on it, they are presented with a popup menu of folders and subfolders to pick their platform etc. It is called Woo Custom Downloads and if anyone wants it, PM me, and I will send it to you. It is not yet available in the WP plugin repository.

I have also implemented notifications in my plugins. It lets users know of new plugin version and points them to a custom page on my website where they can read about changes. If they want to update, they will have to download it from their accounts where they purchased it. So, if someone obtains a plugin without paying, they won't be updating it :)

[Adam_G]

hey @gorangrooves would you mind sharing how you accomplished this?

[gorangrooves]

@argon Are you referring to the update notification system?

[Adam_G]

@argon yes please