RE: plugin XML files

["John B" <home-automation@xxxxxxxxxxxxxxxx>]

Hi Gerry,

> 1) There are no file extensions on the URLs that leads to the
> actual plugin file.  Could someone elaborate on why and/or
> what the "proper" way to manipulate the URL to get at the
> plugin file?  For example, is the proper way to get the
> default/english plugin file for a URL to just suffix the URL
> with ".xml"?

The main reason for not including the .xml was one of security.

Suppose someone hacked your web site and changed your plugin file to
point to a .exe file - xPLHal Manager would then download this and you
have a potential security risk.

So it is assumed that the client application will always add .xml as the
file extension - that way if an attempt was made to download code to the
client, it is less likely to be executed if it has a .xml file
extension.

For English plugins, just add .xml.
For any other language, add -fr.xml, -de.xml etc. depending on the
2-letter language code.

So, if our app was running in a French install, you would first try
plugin_name-fr.xml, then if that failed, you would just use
plugin_name.xml.

> 2) I could see a real benefit to having two additional
> attributes on each plugin entry:
>
> a) vendor=  being the xPL vendorID that this plugin
> describes.  This way, you don't have to parse a name from the
> URL and it provides some flexibility in the URL naming. I
> guess a matter of explicitness vs implicitness.

Fine with me. This is really a result of the one-vendor-per-file
decision, and I have no problem with including it.

>
> b) some sort of type= where the values might be "core" and
> "plugin" (or anything else).  I ask because the first entry
> -- xPL Schema Collection -- isn't really a plugin file.  If
> it where flagged differently from plugins, then I could
> programatically skip anything that was not marked as a plugin.
>   That could allow different xPL "root" info in here for the
> future, but even if that is not desired, it would make it
> easier than having to test a URL or name for a string match.

Yep, I can't imagine any problems - xPLHal (like most XML parsers I
guess) will just ignore anything it doesn't understand.

Regards,

John