RE: Re: plugin XML files

["Ian Lowe" <ian.lowe@xxxxxxxxxxxxxxxxxx>]

I think we'd be much better served with the one xml file per vendor, and
downloading (or at least indexing!) them centrally - going centrally
means we have the option of pushing bug alerts or whatever out to the
clients more easily.

It also means that it's trivial if a vendor stops supporting an app to
move the xml fragment across onto the xplproject website. If the app was
able to point directly to the vendor's own xml fragment, that becomes so
much harder to do.

Ian.

-----Original Message-----
From: ukha_xpl@xxxxxxx [mailto:ukha_xpl@xxxxxxx] On
Behalf Of Mal Lansell
Sent: 29 September 2005 09:30
To: ukha_xpl@xxxxxxx
Subject: [ukha_xpl] Re: plugin XML files

--- In ukha_xpl@xxxxxxx, "John B" <home-automation@j...>
wrote:
> Hi Mal,
>
> > Just a thought, but if the xml is going to contain URLs, how
about
> > we add an element for the URL of the vendor XML itself.
> > An updated xPLHal could know to look there first.  Eventually
there
> > will be no need for you to host links to all the vendor's xml
files,

> > and have to edit them when they get new
domains.
>
> True - though we'd still need the initial master list for new/empty
> xPLHal installs.
>

My original thought of having an about.basic schema could have helped
here - giving the location of the xml file on demand.

In that case, the xml could be per-device and installed with the
application.  The location provided would point to somewhere on the
users hard-drive (we could still have a web url for checking for
updates), and would allow apps to be individually updated, rather than
potentially having to do a vendor's entire catalog of applications at
once.


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

If we adopted the system I mentioned above, we could have one xml per
device.

Mal