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

["John B" <home-automation@xxxxxxxxxxxxxxxx>]

Hi Mal,

> Perhaps the key to all of this is the hub's client list.
> With the rapid heartbeat system leading to quick discovery,
> the client list will be up to date.  Querying the hubs for
> client details should prove a sufficient starting point for a
> front end or diag tool to construct a list of xPL apps.

You're assuming that every app is PC-based.

What about directly connected apps that go straight onto the Ethernet
network - they don't use a hub, so will never appear in any hub client
list - likewise RS485 apps, and in fact any other device that doesn't
use a PC as a host.

> There is still the problem of your send-only devices, but to
> be honest I don't see any way to include those.  If they
> can't receive, then they can't respond to requests or
> implement a rapid heartbeat system - they will just have to
> be discovered when they transmit (in fact, was there ever any
> reason for a send-only device to send hbeats? They are only
> there to tell the hub it needs to send you messages, but if
> you can't receive them, what's the point?)

I think when we discussed that a long time ago, we agreed that if an app
is send-only, there is no need for it to send out heartbeats.
(but it can if it wants to)

> In my proposal for about.basic there was only one item that
> could not go into the vendor xml - the application version
> number.  Perhaps rather than create a new schema, the hbeat
> messages sent by new apps can add a version=... item to the
> end.

I like the idea of using hbeat. As Gerry has already said, hbeat.app
already permits extra items.
Adding a version= element would be really straight-forward, and would
help a lot in debugging.

> This could be stored by the hub in its client list, and
> returned as part of a hub query.  This is backwards
> compatible, since older apps will still be reported, just
> without a version number.

This is where I have to disagree totally!

One of the goals of xPL is to be totally protocol agnostic.

Why do we need hubs? We need them to implement xPL over TCP/IP.
Hubs are nothing to do with the core protocol - just like mutexes, and
everything else that's either OS or TCP specific that we've tried to
avoid.

If we were running xPL devices over something entirely different to
TCP/IP, we might not need hubs at all.

Therefore, IMO relying on a hub to perform client discovery goes against
all the goals of the xPL project.

I don't even like the idea of a hub sending out hbeats and appearing as
an xPL device in it's own right - a hub should just sit there silently
doing it's job.

If we want a faster client discovery than we currently have (which I
agree is important if client apps are to quickly build up a view of the
network) then that should be implemented at the device level.

Gerry's suggestion of a hbeat.request is ideal - all we are asking a
device to do is respond with it's usual heartbeat whenever it receives a
hbeat.request - you can't get much easier than that.

Regards,

John