plugin XML files

[Gerry Duprey <gerry@xxxxxxxxxxx>]

Howdy,

So I'm mired in the tedious chore of editing the plugin XML files and it
has
me thinking.  I know we're dealing with other issues right now (protocol
things), so I'm just throwing these out for thought, not so much action
right now:

1) Root node agnosticism
I really don't think it's a biggie, but it would be nice if the root node
was not "<xplhalmgr-plugin>".  I know it was originally
created for xPLHAL,
but as the role of this file grows as high level definer of xPL
capabilities, a more generic root node would have been nice.  That said,
there doesn't seem like much point in changing it now.

2) Device information
I was surprised at how little information about a device there is (well,
demographic info -- there is plenty of other info).  I know this was part
of
the xPLDiag discussion and such, so rehashing here isn't worth it. 
However,
it would be nice to eventually add a "friendly" description, a
current
version, and a URL for the device in.

3) Config item regular expressions
Big fan of regular expressions myself.  However, it's not clear which set
of
regular expressions are supported here.  There is a wide variety of
different regexp libraries out there and some do more minimal regexp
support
and some do a lot more.  It would be helpful if there was a pointer to the
regexp package to be used (or at least the one used for envisioning the
plugin file) so that a) plugin authors know what they can depend on and b)
developers that want to use this part of the plugin can select a regexp
library for their platform that most closely matches what the spec is.  As
an example, some regexp libraries support the concept of "[0-9]+"
which
means one or more numbers, distinctly different from "[0-9]*"
which means
zero or more numbers.  But not all regexp packages support the
"+" stuff.

4) controltype, menuItem & conditionalvisibility
These items seem very specific to a GUI like xPLHAL but not what a more
generic GUI (or non-GUI app) may need.  I can see controltype a little
easier because it's a single item and easy to understand (and ignore, if
not
needed).  But the menuItems and conditionalvisibility items really get
specific about being GUI (or UI in general) oriented.

I'm guessing this has to do with the historical side of things -- that this
was originally just meant for xPLHAL.  Ideally, user interface items would
either be in a separate xml file that would only be needed by interfaces
that needed them or would be in a separate section of the XML file with a
more generic name than menuItem.

I'm really not carping here -- I understand the genesis of how this file
came into being (well, at least in broad strokes).  And again, I think we
need to live with this for compatibility-sake.

Just some thoughts...

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