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

[Gerry Duprey <gerry@xxxxxxxxxxx>]

Howdy,

>>I guess I'm not really a fan of this.
> I don't really see why not, tbh...

Mostly because it's solving a need that I think should be available to all
xPL apps on all platforms with a program that may not be.  Right now,
xPLHAL
is only on Windows.  Perhaps in the near future, something like xPLHAL
could
be written in a cross platform language like Java.  That will still leave a
lot of platforms out (Java is not really all that pervasive -- less than a
dozen platforms (and less than that run a modern-ish version).

Solving an important issue like device discovery "extra-protocol"
(that is,
not as part of the xPL protocol) seems like we're attaching the need for a
platform requirement (i.e. xPLHAL or something xPLHAL like running out
there) into the protocol.  I do understand not everyone views it that way.

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

But how do you remove the platform as an obstacle.  If xPLHAL was ported to
30 platforms, what about the 31st platform?  (I know, write one for it, but
that is non-trivial and may scare away more folks who don't want to have to
invent everything for a given platform).

>>There is also a timing issue with any sort of "external"
app being the
>
> And that's largely a non-issue.

I guess I don't agree there.  If there is no xPLHAL running when I need to
query for devices, lets assume I start one up.  It starts listening, but it
won't know about all the devices for potentially a longish time.  If the
user also wanted to use a client (even the xPLHAL GUI client) at that time,
they'd have to wait until the xPLHAL service eventually heard from anyone.

If xPLHAL were always running, that would be a different thing, but even
then, there is a blackout period when it starts where it does not know
about
all the devices it could and that it cannot get around in the current
protocol.  So after a powerfail, for example, it could be 10-30 minutes
before a program like a front end is able to enumerate all xPL devices.

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

I agree that protocol docs are not to be tampered with lightly and any such
changes should be well discussed with great effort made to minimize impact
and provide backwards compliance.  I really am very conservative about
protocol changes, but I think there can be a time and place where they need
to be examined and potentially revisited and we may very well be there.

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

Scripting is just another service (you can even run it without the xPL4Java
server), like a GUI front end or anything else.  Clearly the goal in
writing
the scripting was to make it easy to create the links between events and
devices and take action based on them.  But I don't see scripting as any
sort of "special" service -- it's no more or less important than
any other
xPL device on the network.

The scripting service can be added or removed from the network without
depriving it of anything it needs to operate (it may not operate as nicely,
but as long as xPL packets can fly around, the network operates).

I think I understand what you are getting at and again, I don't have a
problem with higher layer tools per-se.  Just depending on them for a
properly functioning network (including device discovery) seems less than
optimal (to me).

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

But what should such a front end do if there is nothing like xPLHAL out
there?  If we're saying it has to be out there, that moves it into the
realm
of the protocol (i.e. base things all xPL authors can expect/depend on).

I guess this really is boiling down to one of two views:

1) Device Discovery belong in the xPL protocol spec

2) Device Discovery (enumeration) belongs above the protocol layer via a
mechanism that may vary depending on implementation/platform.

I added the "may vary" because XHCP, as least as far as I know,
is not
currently part of the xPL protocol.  If there is strong consensus that
device discovery/enumeration should be done via something like xPLHAL, then
I feel we really need to look into making XHCP a bound part of the overall
xPL spec along with a stated need and detailed description of something
"xPLHAL-ish" so there is a consistent document to implement
against.

I know I'm grating on some folks nerves here -- for that, I do apologize. 
I
recognize that this topic may seem like a non-starter for some or may not
be
worth this much debate to others.  I feel it's sort of like the recent hub
discussions -- we had something that was not really well defined (who
starts/runs hubs) and has lived in the shadows/boundary/light-uncertainty
and cleared away the  potential confusion/uncertainty around it.

That's what I'm help with here -- clarity about device
discussion/enumeration.

Gerry

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