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

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

Hi Gerry, it's late here, I just got home from a party - I'll comment
more in the morning, but for just now, don't worry about rubbing people
up the wrong way... I don't think there is any bad blood on the list
here, and I for one see this as a healthy and robust exchange of ideas,
rather than any sort of argument.

On a basic level, I think you are right - this comes down to whether we
insist that xplhal like functionality (or some minimal subset of that
functionality) is considered part of the base protocol. My instinct is
yes, but let's think about this one.

Ian.


-----Original Message-----
From: ukha_xpl@xxxxxxx [mailto:ukha_xpl@xxxxxxx] On
Behalf Of Gerry Duprey
Sent: 25 September 2005 01:17
To: ukha_xpl@xxxxxxx
Subject: Re: [ukha_xpl] Re: xPL announcement/description protocol -- was
xPLDiag

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



xPL Links: http://www.xplproject.org.uk http://www.xplhal.com
http://www.xpl.myby.co.uk
To Post a Message: ukha_xpl@xxxxxxx
To Subscribe:  ukha_xpl-subscribe@xxxxxxx
To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx