[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: plugin XML files
Howdy,
Sorry for the flurry of notes on the plugins.xml file, but I'm building a
framework around fetching/caching it and the vendor plugin files, so I'm
running into lots of little things.
So, in summary, here are a few ideas I'm thinking of
1) consider adding a vendorid= (or just vendor=) to each <plugin>
line that
is the ID used in xPL messages headers for this vendor (usually the same as
the file name, but why be implicit?).
2) consider adding a type= to each <plugin> that lets a reader
differentiate
a really plugin file ("plugin") from something like the schema
collection
info ("core" or "schema") without having to parse out
names.
3) consider adding a list of plugin.xml root servers to the file. As
changes in the servers occur, the downstream client apps can then
auto-update the servers they hit without having to release new software
updates (with presumably hard-coded URLs).
4) (new with this message) consider adding a version= tag to the root
element. This way, clients can periodically "sniff" the
plugins.txt and see
if what they have is the most up to date.
All of these can be worked around, but if they could be done without
causing
backward compatibility problems, I could really see some benefits to
downstream client plugin management.
Gerry
--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org
xPL Main Index |
xPL Thread Index |
xPL Home |
Archives Home
|