Re: plugin XML files

[Gerry Duprey <gerry@xxxxxxxxxxx>]

Howdy,

> We'd also need to set in stone the one vendor per file issue discussed
> previously.

You know where I stand on it (firmly in the "one file == one vendor
camp" :-)

And if we do this, we can factor a few of the newly proposed tags like
this:

On the root node (currently xplhalmgr-plugin)
vendor=  Vendors full name
version= version of this plugin file
plugin_url= "official" URL to fetch this file and future updates
info_url= URL to informational web page for vendor

On each device node:
description= textual description of the device
version= version of this device
info_url= URL to informational web page for this device

The optional additions to the root would allow for "smart"
automatic updates
to the plugin file in the future.  If the URL and version are provided, the
app could go there and check the version # and if it differs, update the
plugin file (or it could just tell the user to do it, whatever -- that is
up
to the app).  If there were a URL and no version, it could still offer a
manual button/item to the user to cause a forced download/update.

The additions to the device node have been discussed already and I think
they are good, though I've suggested renaming url= to info_url= to signify
this is a pointer to human readable webpage about this device.  If it's
missing, the user can drop back to the root nodes info_url= (if present).

I would imagine all this stuff -- version, description info_url, plugin_url
would be optional -- if someone can include it in their plugin file, great
-- the "downstream" apps can do a better job at identification
and updating.
If the plugin author  doesn't include them, hopefully downstream apps that
care can "degrade gracefully" (i.e. if there is a description but
no "plugin
url", the app could still should a description of the device while not
offering a direct plugin upgrade option).

> Yep - though due to changes in our own hosting arrangements, the
master
> plugins file will be moving to a new site shortly.
> xPLHal will always try the backup mirror if it can't contact the
master,
> so users will stillbe able to download plugins - but it may be more
> difficult to make updates to the master file.

Here's a question -- can tools other than xPLHAL access that website that
hosts the vendor plugin files?

I ask because I'm putting the finishing touches on a new xPL API for
xPL4Java that will make it trivial to parse (into a useful format) the
plugins file, with the hope of making it as easy as possible to use this
info for "smart" front ends.  And if it's OK, I'd like to
eventually even
offer an option to fetch plugin files for newly discovered vendors.

I can easily see this placing a largish load on the identified server, so
I'm completely OK if the answer is "no" or "not right
now" or "I'd rather
not".  Figured it couldn't hurt to ask :-)

Gerry
--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org