Auto Update Schema

[KingArgyle]

Plugin Detail Schema Available on Wiki:

Plugin Detail Schema

Comment Period: At least one week, maybe more depending on participation.

Okay. I've looked over the requirements that everybody have suggested, and tried to combine these into an XML file, that can be extended as we need it.

1. PluginDetail.xsd - Schema describing the PluginXML File.
2. PluginDetailSample2.xml - An XML File that validates against the schema.
3. PluginDetailSchema Doc. - This is the Documentation describing the Schema. It is in HTML and should give an idea of what each of the Elements.

The GBPVR element is the Root element.

Most of the elements are Optional because they may not apply. There are two areas that this Schema covers. Skins and Plugins. Each group is optional. Whatever program reads this information in will have to require one of these elements.

Items that need to be decided:

1. The Plugin Categories need to be decided. Right now I'm suggesting the following: Utility, Video, Music, System Info, TV, Other

2. The schema is designed on purpose not to have very many attributes. Yes there are lots of Elements, and yes they are pretty long, but Readability and expandibilty are easier to do this way, then to tie everything to attributes. The only times attributes are used are to indicate types or versions.

3. Additional Information needs to be defined for Plugin Installation and Skin Installation.

4. Additonal GBPVR System requirements probably need to be defined.

Anyway, this is a working draft, and ready for the group to review and make comments.

After we get this part done, and defined, I'll look over the schema required for retrieving the available plugins.

[dottore]

nice work, will have a look at the files later, just one question: those files are managed by the plugin developers, but we need a main update.xml, which links to the plugins/skins....should this be done as xml or would a list be enough? what do you think?

after getting the schema done i will start the development.

[jrockintuitive]

Good job King. Very thourough.

For dates can we standardize on a format - I find yyyy-MM-dd is the most system friendly.

I didn't see a reference to required files that are not skins.

How do we handle quasi required files like postprocessing.bat. when I install new plugins I do not overwrite my batch files- I update them, if appropriate.

Are we handling multple skin files for a skin (I plan on doing this with Guide2J) and multiple skins (Blue, Red Sky, etc).

We talked about creating a settings file. Although, I don't think we need to handle this file specially, I wanted to bring it to the forefront in case you guys think we need to give this file special attention.

[KingArgyle]

Actually, in the long run, I didn't see the developers having the create these XML files. I saw these files as being used as the data layer for a REST web service that retrieves information for a particular plugin. For example, if the wiki supports it, somebody could write an app that collects all the information and stores it in a backend database. Then when the Auto Update plugin makes a request for Detailed information about a plugin, the PluginDetail.xml file with a reference to the Schema is sent to the plugin. The plugin then reads the information and displays it as is needed.

Jrock: Do you have a specific Element name or Type that it should be under the PluginDependenciesType? I could use Other, but that is almost to generic a term.

Also, as for multiple screen skin files. We need an installation component section to this Schema that is used by both the Skinning and the Plugin sections to describe what files are included and where they are to be installed. This can be used to verify an installation.

[jorm]

The schema is very good. Great work.

It would be nice if we can get this information automatically. And would simplify my life a lot.

One thing that I dont see. What about files?

It would be nice to have files that get copied in certain locations. For example if someone installs xrecord I want to provide a priority recordings.xml only if one is not on the system already.

So maybe
<files>
<file>
<name>priority recordings.xml </name>
<!-- from the zip -->
&lt;sourcepath&gt;/gbpvr/priority recordings.xml&lt;/sourcepath&gt;
&lt;destinationpath&gt;$gbpvr&lt;/destinationpath&gt;
&lt;override&gt;false&lt;/override&gt;

[KingArgyle]

Jorm that is what I would like covered in the Installation section common between the Skinning section and the Plugin section. If we can come up with something that works with both that would be great.

[jorm]

sounds good.

[jrockintuitive]

King, I think Jorm hit it on the head with &lt;files&gt;... or something like that. This would cover all of the question that I had.

I think if the installation and description was in one file, that would be usefull

[KingArgyle]

Okay, I'll take a look at modeling this for the Skins and Plugins in the next few days. Have a little slow down until about Monday when work will get very busy again.

Anyways, any other comments? Haven't heard anything from Reven yet. He's unusually quiet.

[reven]

Quote[/b] ]Haven't heard anything from Reven yet. He's unusually quiet.

been busy, and i trust you to get it right

only two real thoughts, the version number should be completely unique, so i suggest this always use the build/assembly number, xrecord uses live v17, but a build number is more accurate. and i hope someone is planning on a writing a app to generate most of this info for use, cause well, i wouldnt want to do the entire xml file by just editing it. but most part seems right.

the auto update plugin itself:
wondering about auto update, and bandwidth, mostly for skins (and skins supplied with plugins), since its becoming an issue, is there anyway this will be able to only download the updated/missing parts from the zip file? like i just updated my videos, but only changed the dll and the skin.xml file, and updated media experience and only changed 2 files. this would require the server to do more thinking, but less bandwidth would be used. of course then the &lt;file&gt; thing suggested would have to be implemented. assumptions could be made about what the client has by which version of the skin/plugin they are currently using, so the &lt;file&gt; would need a attribute/node of when it was last add (by the version/build number, not date).

and i think the plugin should be inside a settings plugin, best place for it, but also with a panel which looks similar to a news ticker of the new plugins/skins.

ok thats my 2cents