Re: Re: xPL announcement/description protocol -- was xPLDiag

[Gerry Duprey <gerry@xxxxxxxxxxx>]

Howdy,

> Wow - we have all been busy this morning, huh?

As the proverbial beaver.  I'm actually happy as I think that this reflects
a minor refinement phase for xPL.

Any successful protocol I've been involved with or observed over the years
tends to go down one of two paths:

1) Poorly thought out -- people try to use it -- people have massive
problems -- minor fixes don't help -- protocol scrapped for a new protocol
-- people lose interest -- protocol dies.

2) Well thought out protocol -- people try to use it -- most folks are able
to with good success -- after a period of use, some minor refinements are
debated (nothing is perfect from the start) -- compatibility issues are
addressed in logical means -- the protocol compatibly evolves -- more
people
get interested -- protocol (usually) succeeds.

Clearly, I think xPL is #2 and what is happening is the natural consequence
of a growing user base hitting some of the boundary conditions in the
protocol.  As Martha would say -- "It's a good thing"  (that is,
just before
she strangles one of her assistants for not getting the butter melted at
the
exact temperature she demanded :-)

> Firstly, I can see where Tony's frustration is coming from - there's
> always a tendency to overengineer things like this, and one of the key
> design goals of xPL was to produce a *very* simple implentation, which
> could be ported onto anything (down as far as microcontrollers) and
> remain fully compatible.

I agree -- changes need to be as backwards compatible as possible

> In that regards, I don't really like the idea of extending the
> heartbeats - the hbeat schema is a pretty fundamental thing, and at
> present, it's increidbly easy for the smallest of devices - adding a
> response element makes it "chunkier".

Well, the part about the hbeat.app I like and was pushing is that really
small devices will likely not be able to do much more than send a heartbeat
out (these devices often have minuscule amounts of RAM).  In their case,
they don't need to find a way to cram a new message identifier into their
memory and to participate at the simplest level, all they need to do is add
a little code to watch for a message (and they can check and just check the
schema class/type if they are super cramped on space) and spit out a
standard heartbeat (which they already have code to do).

> As for a separate "about.basic" schema - there's no good
reason not to
> have this, and I think it should be added to as many apps as
possible...
> *but* xpldiag should treat this as an added bonus, not a required
item.

Agreed about the "bonus".  However, I really feel, from a
compatibility
standpoint, at least the response still needs to be a hbeat.app/config.app
message.  These messages already support additional data items (if the
device has them to report), so we're using the protocol as speced.

As for triggering the sending of those messages, for that, while I like the
idea about hbeat.request (because it so neatly fits into the status request
idiom discussed in the xPL protocol docs), I could easily support something
else (like about.request or about.basic) that caused the heartbeat to be
sent.

> As we move towards ever greater xPL management (and smart frontends,
> which is where this is all ultimately heading), the vendor's xml files
> will become more and more important.

Yes, but....

1) As you point out, location of the XML files is an issue that has to
solved on every platform and especially on platforms like linux, you're
going to have people going ape-poopy over whatever choice you make (saying
that the decided location is wrong or wrong for them, asking to have a
single line config file in /etc that is a vector to where the files really
is, etc).  It's not an aspect I like about the linux/unix/bsd community,
but
I can pretty much promise someone will be getting all verklempt over it.

2) Managing those XML files becomes a chore.  I have 6 PCs in my house that
run various xPL applications as well as 4 touch screen system in the walls
that also run xPL apps (the touch screens have no local storage).  I also
have a few dedicated xPL devices (things that aren't full out computers,
but
control hardware and speak xPL).  Not all of them would need the XML files,
but even for the PCs and the touch screens, keeping them all up to date as
new devices are added and updated is a chore.  Using things like network
shares to access a common repository can help, but for many devices, that
is
not always necessary and they'd need copied installed on them.

3) I really like the ability of a program, like a front end, to hear from a
device it's never heard from before, query that device for info, learn
about
it and allow some level of control over it (as long as it supports a known
schema class).

So, in short, I feel the XML files are fine and we should have them, but
depending on them for device information is going to be less dynamic and
more of a management headache.  I feel if an app can use them, it should,
but it shouldn't be a requirement (not that anyone suggesting it should be
a
requirement, but).

> I'm seeing three levels of info - the very simple app that doesn't
> support about.basic, which is described in the vendor's XML file
(which
> we may wish to do is add more elements to the xML file to include a
> bunch of author information, support website details etc)

Okay -- but if it at least could respond to an about.basic or about.request
by sending out a heartbeat, the initiating application would then be able
to
learn it exists and then lookup info for it in the appropriate XML file.
Without that minimal ability (i.e. device discovery), the app/front end may
not hear about the device for a long time and if the app is a simple
configuration app or similar, it may not typically be run by the end user
long enough to eventually heart from all devices.

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