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

[Gerry Duprey <gerry@xxxxxxxxxxx>]

Howdy,

> A "bit of a cheat" - I love that!

I'm not trying to be mean with that line and perhaps it's more a dramatic
turn than not.

> I'm guessing by that comment that you've never even read the XHCP
> specification, and haven't a clue what it does - in which case you're
in
> no position to pass judgement.

I have read over the XHCP protocol and have a reasonable understanding of
it, but I've never implemented it (because it's only implemented in xPLHal
and that is only under windows).  I'm not trying to pass judgment on it as
a
protocol -- my concern is using it (and to a greater extent) xPLHAL to do
something that *I* feel should be done at a protocol level.

Obviously, I've touched a nerve here and I apologize.  I'm not trying to be
critical for the sake of being critical, but am addressing a few points I
think may be important.

XHCP is fine and as a session oriented protocol, I get it.  It just seems
to
me that if a xPL device wants to talk to it for info on other xPL devices
(in the context of this discussion thread), that means that app has to
implement at least two protocols -- xPL and XHCP.  That may be more than
smaller apps can afford (engineering time, resources (RAM/ROM)).

> I'm not even going to go into the detail as to why XHCP exists - Ian
has
> already mentioned some of the reasons, and the protocol document is
out
> there for all to read.

I really do understand it.  I think it would be great if something like
xPLHAL could provide much of the info it does via XHCP through xPL too so
apps that don't need session oriented connections/streams could get by with
a single protocol config.  But that is just a thought, not meant as a
tear-down on xPLHAL.

> If after reading it, anyone thinks that it can be replaced by a load
of
> xPL messages, I'll be happy to hear from them.

Not replaced.  xPLHAL is fine as it is.

But, as a person who cannot use it because it's written for a platform I do
not have access to, I'm **very** leery of any suggestion that xPLHAL (or
any
program) should be part of a functioning xPL network, or at least a
suggested part, for higher level functions.  It's a sore spot.

Even if a Java version of xPLHAL (or an equivalent) were created, it still
not going to be available for all platforms (Java, while semi-wide spread,
is still not available on many, many smaller platforms).

xPL, up to now, has been a nice, clean, compact and above all,
platform-neutral protocol.  I really am trying to make sure we keep the
spirit of that at heart in these discussions.  In that vein, while xPLHAL
is
a great service and a great model for like services, I don't think it's a
good idea for us to try to solve protocol level things with it (and I do
understand not everyone is buying that this should be a protocol level
thing
-- but the protocol is the only "common denominator" disparate
xPL apps have).

Again, my apologies if I got anyone hot under the collar -- that is not my
intent.  I'll try to be more respectful of xPLHAL in the future.

Gerry


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