I like the idea but my only concern would performance. If it doesn’t contribute to xruns then I’m sure it would be a good addition.
I do wonder though if a Check For Updates option would be better all round. Even 35 seconds would seem like a while for someone who didn’t know that it will indeed refresh fairly soon, and I would imagine that by 20 seconds of sitting there waiting they will restart anyway. The user having control over when it refreshes and them not waiting at all/knowing what is happening is more appealing to me overall.
All these concerns about performance are misplaced. There is no reason this would impact performance, and I’m 99.999% sure Andrew would not let that happen.
I think the best option is actually long-polling to the API server. This allows modules to be immediately available when adding/purchasing a module/plugin.
This behavior will be enabled by default, and a settings.json property will allow you to disable this long-polling, checking plugin updates at launch, and checking for new Rack versions.
For browsers, HTTP times out after 30s or 60s or something, but I can do whatever I want with libcurl. However, I think it’s best for the server to return after 55s or so regardless, in order to not confuse firewalls and proxies.
long polling or a websocket to the server where you can push a message on purchase. The other option would be to register a client protocol like this rack://update and provide a link like “Update plugins” it on the purchase site.
the websocket should be quite forward. Do you transpile the library with webpack or using plain Javascript. Would be willing to help out for free, if there is some demand.