aut-update

[sub]

Quote[/b] ]does the plugin helper provide such informations?

No, it doesnt. The only place in GB-PVR that has a version number is in the config.xml.

[reven]

or you could use the config (i didnt know it was in there)

[KingArgyle]

I've got the necessary tools to do the Schema so that is no problem. Just need to know what the requirements are, so it can be designed. I'd suggest going through several iterations of the schema design before one once of code is written. Much easier to work with something if you already have your features defined. The schema should do that. Once you have the schema, you can then generated some C# Binding classes to work with the XML file.

[dottore]

good idea. first of all we need the information, if it is a plugin or skin, the name of that, the path to install to, the gbpvr-version...

other ideas?

[reven]

a description of the plugin, so the user knows what they are downloading (possible features, so can be displayed seperate from description). last updated (so the user knows if the plugin is actively maintained). screenshot (so can get a preview, screenshot is just a url, check image against one found in cache before downloading).

[dottore]

skin-"compatibility", means, which skins are included in the plugin. maybe release notes and skin-changes.

[blader_se]

I just found this thread, and it sounds interesting....

A couple of thoughts have entered my mind:

What level of automation do you aim for? I'd settle for if I can do a request and get information about which plugins that have changed - and what has changed, together with an easy way of downloading new stuff.

If you go into auto-installing (I don't know what jeffs installer do), I'd like a way to rollback if it did not work. Have you thought about the problems with dependencies and version control? There are a number of package installers out there...

I'd really like a way to check the version on installed plugins. Perhaps the configure application is the best place for this? Perhaps the update plugin should be a plugin for the configure app (is this at all possible?)

How will you package things? The plugin is simple enough, but what about skins? Should you go all the way and say that each plugin has a corresponding package with that plugins part of a skin. It would mean that I have to download more skin packages, but lesser total number of bytes (since I can skip the parts that belongs to skins I don't use). It would also mean that I can directly see if my favourite skin supports my favourite plugin.

Unforntunatly, I'm leaving for a couple of weeks holliday, but I'll gladly assist you in any way I can.

Meanwhile, you can always parse the wiki upload directory for dates, to see if a zip file has been updated.

[cginzel]

My $0.02, I'm lazy and I don't use many plugins, so ideally, for me, this feature should allow me to always automatically update (with easy rollback) and it should tap into a database which defines which skins are compatable with which plugins and compare that to my currently selected skin and selected plugins (more advanced option would be to compare to all installed skins and plugins! and just update my machine when new versions are available and install and restart GBPVR (assuming I'm not currently using it or recording)... The compatability database should be updated by the skin and plugin authors so they can specify which they've tested and confirmed work together.

That's all

[KingArgyle]

More we get into this the more it looks like we are discussing a set of Web Services, with the XML describing what is available, and then it would be up to the back end system to determine how it actually stores the information. Information stored in the back end system would then be used to populate the XML files sent to the requesting update plugin. I would recommend keeping to a simple REST architecture, there is no need to complicate it with SOAP.

[dottore]

you're right. i would keep it as simple as possible. xml-files for every plugin on the server-side, one main xml-file on gbpvr.com and a plugin parsing those informations.

things like skin-dependency could be resolved by adding them to the xml-file. if there are skin-changes, the plugin should report this in the xml-file, so the update-plugin can copy the files from the blue-skin (if the user wants this).

more should be added in a second release.