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

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

> I guess I'm not really a fan of this.

I don't really see why not, tbh...

> It would require a piece of software that not all folks want to (or
could) run.

As mentioned seperately, the "could" aspect of this is something
we need
to address - if you remove platform as an obstacle, find me any
automated home that doesn't have a machine running 24x7?

> *if* xPLHAL is running and *if* the app knows how to talk to it.

Remember we are talking about one specific class of apps, not a general
requirement for all xPL apps.

> Another issue for me is the need to create yet another protocol to
handle this (XHCP).
> Frankly, I sort of understand why this exists, but I feel it is
perhaps a tiny bit of a > cheat -- why can't xPL Hal do all this work
using the existing xPL protocols?

Firstly, remember - xplhal is the low level server, xplhal Manager is
the client.

Here's the thinking behind this - we opted right from the start to use
the best available protocol for each job. It is possible, for instance,
to wrap HTML pages into the body of an xPL message, but we took the firm
decision to use HTTP instead - it's valid to pass URLs across xPL, but
not HTML.

When you look at the properties of xPL - it's broadcast based, and uses
UDP so it's not sessional, has no connection state, etc.

What XHCP does is much more inline with SMTP, HTTP, POP3 etc -
client/server based applications.

It's not apropriate to use a UDP connectionless protocol for these sorts
of tasks, just as it's totally inappropriate to use a TCP based
connection based protocol to pass around simple telemetry/control and
status messages like xPL.

It may be considered a cheat to use XHCP, but it's 100% in line with the
design philosophy of the protocol to do so - use the best protocol for
the job in each situation.

> My xpL4Java container server is managed that way and xPL and I've felt
no
> limitations/restrictions.  Having a protocol (xPL) that depends on
another protocol
> (XHCP) seems a bit burdensome.

Consider that the vast majority of internet users send their email by
SMTP, but receive it by POP3 or IMAP instead - we browse websites and
happily move between HTTP and SSL - I thnk what matters is the end
user's perspective rather than the wiring on the underside.

> Unless the network cannot or does not want to use xPLHAL.  Then
something that I
> honestly feels needs to be in the protocol itself is now dependent on
a piece of
> software that may not be available.

"Cannot" is an issue we can address - "does not want
to" is (I feel) a
matter of explanation.

> There is also a timing issue with any sort of "external" app
being the
tracker of
> devices.  The same problem we started with really -- that app will
have to be running
> for at least X minutes (9 to 30) before it will have heard from all
devices.

And that's largely a non-issue.

Fundamentally, we are using UDP broadcast without checksums,
acknowledgements, any sort of message fingerprinting or, when it comes
down to it, *ANY* assurance whatsoever that messages will be delivered
reliably.

That's the nature of the beast - the system may not offer instantaneous
response, nor 100% accuracy, but it is very accessible.

> I really feel that this should be addressed in the protocol first.

The protocol is pretty much a locked document - it has served us well,
and I don't see the need for changes at this point.

> Yeah, I'm being a bit pointy here, but I really feel (as I've said a
few times now) that > this needs to be solved first at a protocol level
and then we can move up.

Firstly, don't worry about it - I get the point ;)

Here's the thing - within your Java framework, you have implemented
scripting. Why?

I'll assume the reason is that you want to have the capability to react
to certain xPL messages by sending other messages, or taking other
actions on the basis of the information received...

And with that step, you demonstrated why we need that extra tier of
functionality above the base protocol.

xPLHal exists for pretty much the same reason - we acknowledge the need
for central intelligence and direction within an otherwise distributed
network.

This is well defined engineering territory here - the HTTP specification
doesn't go into any details on the acceptable tags to be used within
documents - that's up to HTML, a completely separate standard, which is
*utterly* dependant on HTTP for it's operation.

IMO, XHCP is an excellent way for smart clients and frontend apps to
discuss xPL events with servers and other abstraction nodes which handle
the low level xPL, which is, in turn the best protocol for delivering
simple, fast telemetry information around the home network.

Ian.