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

[Gerry Duprey <gerry@xxxxxxxxxxx>]

Howdy,

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

I guess I'm not really a fan of this.  It would require a piece of software
that not all folks want to (or could) run.  I feel that something like this
(and in particular, the device discovery aspect) needs to be at a protocol
level so anyone can do it and not have any other software requirements.

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

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

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

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

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

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.

>>Purists may cry foul at the idea of hubs sending their own xPL

Technically, I don't have a problem with a hub sending messages if it were
to make sense.  However, I don't think the hubs should be the repository
for
information that then needs to be queried (i.e. device discovery) -- that
seems like a small variation of the xPLHAL issues I mentioned above.

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.  That means even if other apps were to lean on
xPLHAL or a Hub for listings of "known devices", you still have
the
startup/wait issue for a newly booted system.

I really feel that this should be addressed in the protocol first.  If we
then decide on certain "best practices" above the protocol (like
coming up
with the idea of a central registry (hub, xPLHAL, etc) that *can* be used
(but does not have to be used), that provides the flexibility that allows a
full range of implementation.

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

* I run linux and xPLHAL doesn't run on linux
* I run Mac OSX and xPLHAL doesn't run on OSX
* I run Solaris and xPLHAL doesn't run on Solaris
* I run BSD and xPLHAL doesn't run on BSD
(etc, I'm know I'm being annoying with that enumeration :-)
* I don't have a machine on my network that I can dedicate to
running xPLHAL
* I don't want to have to run a separate PC with xPLHAL 24x7 for an
otherwise simple network that would not otherwise need it.

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.


Gerry

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