Plugin Update Notification/Updater

[boroda]

yes, Steven, at least i expect something like this.

[redwing]

Then skins (both xml & xmlc) & TM need to include just name and version at the beginning of the code?
Maybe name could be optional if it's the same as filename? I think that's the case for most skins except skin sets.

@Steven;
How about allowing, optionally, each plugin to use its own sub-folder under MusicBee\Plugins folder?
Some plugins are using the same filename for different files and Plugins folder is quite messy.

[boroda]

for update notifier ui: i think that displaying message box with updates at mb startup would be very boring. its better to have a button on mb title bar with image of balloon and number of updates. user can click this button to view the window with all updates. just like in visual studio. also an option to ignore given update (not to remind about it anymore) might be useful.

[derTyp]

Yeah good idea. I think we need to establish a standard way to store the addon data that can be readable by the updater. I am thinking of XML file that stores the important data, maybe something like this:

Code

<?xml version="1.0" encoding="UTF-8"?>
<addon-data>
	<name>Addon anme goes here</name>
	<id>addon id according to the website dashboard</id>
	<version>1.0.1</version>
</addon-data>

if needed we can add more field in future.

Also the .xml file naming scheme should be something like

Code

addon_*.xml

then the updater plugin can search through the directory and looks through all the files by that naming scheme and checks if a new version available or not. It shouldn't be too hard.

maybe i have misunderstood what is being proposed, but i had understood that when a plugin (or skin) is updated on the addons page, that the update would get included in a queryable xml block, similar to https://getmusicbee.com/rss/
if thats the case, i am happy to have MB query that xml data and for anything matching the user's installation and alert them.

yes, Steven, at least i expect something like this.

I maybe wrong but the suggestion of AvikB was to add an additional file per plugin in the plugin folder, at least that's how I understood it. So you would have for example a mb_plugin.dll and a mb_plugin.xml file. The xml file holds the information for the updater (website id, name) and everything else would still be in the .dll (the PluginInfo object).

So the updater can read the xml, query the website (over the existing API) for the latest version, compare it to the one in the PluginInfo and then display a notification.
I would not add the version to the xml because you would have to change the version in two files and we already have the version in the PluginInfo class. This way you could even generate the xml and download it over the website when you create a plugin, because it would never change.

[boroda]

So the updater can read the xml, query the website (over the existing API) for the latest version, compare it to the one in the PluginInfo and then display a notification.
I would not add the version to the xml because you would have to change the version in two files and we already have the version in the PluginInfo class. This way you could even generate the xml and download it over the website when you create a plugin, because it would never change.

but this wont work for theater modes, visualizers and skins. i don't think its very hard for devs to include 1 small xml file into add-on zip.

also i wouldn't rely on add-on version at all. for example there is no versions at all for most skins. update date is most important for comparison of versions.

[Freddy Barker]

@Steven;
How about allowing, optionally, each plugin to use its own sub-folder under MusicBee\Plugins folder?
Some plugins are using the same filename for different files and Plugins folder is quite messy.

+1

A good idea 

[derTyp]

So the updater can read the xml, query the website (over the existing API) for the latest version, compare it to the one in the PluginInfo and then display a notification.
I would not add the version to the xml because you would have to change the version in two files and we already have the version in the PluginInfo class. This way you could even generate the xml and download it over the website when you create a plugin, because it would never change.

but this wont work for theater modes, visualizers and skins. i don't think its very hard for devs to include 1 small xml file into add-on zip.

also i wouldn't rely on add-on version at all. for example there is no versions at all for most skins. update date is most important for comparison of versions.

I honestly forgot about Skins so yeah including everything what is needed in the xml would be the better option

[AvikB]

  @AvikB, so would the xml block you describe be available similar to: https://getmusicbee.com/rss/ ? I would suggest including the update date/time in UTC format as well in case the plugin developer forgets to increment the version info

Yes, kind of similar.

@Steven; How about allowing, optionally, each plugin to use its own sub-folder under MusicBee\Plugins folder? Some plugins are using the same filename for different files and Plugins folder is quite messy.

This would extremely useful.

Then skins (both xml & xmlc) & TM need to include just name and version at the beginning of the code? Maybe name could be optional if it's the same as filename? I think that's the case for most skins except skin sets.

Some skins are in binary format. so that won't work.

but this wont work for theater modes, visualizers and skins. i don't think its very hard for devs to include 1 small xml file into add-on zip.
also i wouldn't rely on add-on version at all. for example there is no versions at all for most skins. update date is most important for comparison of versions.

Right now i think my priority is to have an plugin updater. I will add update options for skins and others at a later date.

So the updater can read the xml, query the website (over the existing API) for the latest version, compare it to the one in the PluginInfo and then display a notification.
I would not add the version to the xml because you would have to change the version in two files and we already have the version in the PluginInfo class. This way you could even generate the xml and download it over the website when you create a plugin, because it would never change.

but this wont work for theater modes, visualizers and skins. i don't think its very hard for devs to include 1 small xml file into add-on zip.

also i wouldn't rely on add-on version at all. for example there is no versions at all for most skins. update date is most important for comparison of versions.

Yes i think Steven and you are right about using the update date.

@AvikB: if you write example update notifier plugin to integrate it into mb later, write it in visualbasic as mb is written in vb.

About that..... i am not comfortable with VB    . I will write it with C# and WPF. maybe winforms but i like WPF better so there you have it. I don't think it needs to be integrated directly into MusicBee. It should be a standalone plugin, maybe included with MusicBee by default.

for update notifier ui: i think that displaying message box with updates at mb startup would be very boring. its better to have a button on mb title bar with image of balloon and number of updates. user can click this button to view the window with all updates. just like in visual studio. also an option to ignore given update (not to remind about it anymore) might be useful.

I will keep that in mind. But before that we need a working solution first 


I will start working on a updater system this week. hopefully i will have a standardized structure for the XML data and an basic update notifier.
Let me know what do you guys would like to see.

[redwing]

Then skins (both xml & xmlc) & TM need to include just name and version at the beginning of the code? Maybe name could be optional if it's the same as filename? I think that's the case for most skins except skin sets.

Some skins are in binary format. so that won't work.

I don't understand why that won't work. Steven, can't MB read version info in xmlc file if it's included in the source skin file?

[AvikB]

I don't understand why that won't work. Steven, can't MB read version info in xmlc file if it's included in the source skin file?

Steven did mention that it would require updating the older addons or it might cause issues.

I dont see a id working as a matching criteria unless some changes were made to the plugin "about" information block, but i don't think i want to do that due to breaking existing old plugins.

using XML manifest would be better in this case. and also i can provide an option in the dashboard to auto generate the XML file. you can just download it and include it in your addon.


Here is the link for the github repo, it has no functionality added yet. I just added readme and a list of todo.
https://github.com/Avik-B/MB_AddonUpdater

[redwing]

i can provide an option in the dashboard to auto generate the XML file. you can just download it and include it in your addon.

You mean include it as a separate xml file? So for each skin file, there's additional xml file just for update notice and users should keep them as well? I don't think that's a good idea for skins and TM views (though it won't matter for plugins). It would be better including the code in the skin file. Still I don't get why you think old xmlc files would matter. With no such info in the file, then no update notice. What am I missing here?

[Steven]

I am not getting why its really necessary to include an xml manifest file with a plugin.
Isnt it enough that when a plugin (or skin) is updated on the add-ons page, that a queryable xml file is updated with the plugin (or skin) name and the date/time it was updated.
Then all MB needs to do is query the xml file and compare the updated names with the last updated time that MB will cache and anything newer, alert the user.
If you have more advanced things in mind then fine, but otherwise it seems on the surface to be more complicated than needed.

[AvikB]

I am not getting why its really necessary to include an xml manifest file with a plugin. Isnt it enough that when a plugin (or skin) is updated on the add-ons page, that a queryable xml file is updated with the plugin (or skin) name and the date/time it was updated. Then all MB needs to do is query the xml file and compare the updated names with the last updated time that MB will cache and anything newer, alert the user. If you have more advanced things in mind then fine, but otherwise it seems on the surface to be more complicated than needed.

The problem is how are you going to query that xml file? Right now the data is stored in the Database with an unique ID, and the only way to query the data is to use the ID. You can not query using the name.

[Steven]

i dont know how you did it, but http://getmusicbee.com/rss updates every time i update the musicbee version

I dont need to query by name - i just need a full list of names and when they were last updated

[AvikB]

 You mean include it as a separate xml file? So for each skin file, there's additional xml file just for update notice and users should keep them as well? I don't think that's a good idea for skins and TM views (though it won't matter for plugins). It would be better including the code in the skin file. Still I don't get why you think old xmlc files would matter. With no such info in the file, then no update notice. What am I missing here?

No that would be bad idea. The XML file will store the "last updated" date as well, which will be modified by the updater. If i put that in the SKIN XML file, then i would need to modify it as well. Which i don't think is a good idea.