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

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

> Perhaps the key to all of this is the hub's client list.

Personally, I still see xplhal as the key - the hub holds the client
list for a single PC - xplhal has the whole network view.

> 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.

I see it as two separate needs - a front end needs complete information,
the diag tool is going to be used to tell if that "complete" info
is
accurate!

> 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?)

The heartbeat isn't just for the hub - it's there to tell xplhal (or
another config server) that it's there, and how often to expect an hbeat
- this allows a simple health check on the device - if a wee device's
hbeat says every 4 minutes, and you didn't hear from it for 13mins (ie,
missed two slots) you can tell the human that the device seems to be
faulty/off/blocked/whatever.

> 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 this - it's elegant and simple, but provides a lot of the
benefits we are looking for..

> 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.

Of course, it could equally as well be stored in the xplhal server, and
be used in the same way.

> The requesting application would build it's initial app list from all
the responses, and > from then on would maintain it by monitoring hbeats
in the same way that the hub does.

But this is completely redundant - xplhal has all of this information
available already accesible using XHCP.

I can see a benefit of adding the request response you suggest, but I
don't believe that this should be something that a front end does itself
- this would be a powerful mechanism  to ensure xplhal is up to date.

Basically, I agree with the mechanism, but don't think it should be used
quite the way you are suggesting.

> The messages would look something like this:

(message structure is good)

> Purists may cry foul at the idea of hubs sending their own xPL
messages, but it would be > better to use a method that we know is
working than try to open a new port with all the > firewall etc issues
to go through again.

I don't see this as an issue.

> Mal

Let me turn the question around - why would you prefer to not use the
xplhal server (or it's equivelant) as a cache of the xPL network state?

Ian.