Re: xPL Hal in a loop

["Mal Lansell" <mlansell@xxxxxxxxxxxxxx>]

Thoughts?  Anyone?

Mal

----- Original Message -----
From: "Mal Lansell" <mlansell@xxxxxxx>
To: <ukha_xpl@xxxxxxx>
Sent: Wednesday, September 08, 2004 9:51 AM
Subject: Re: [ukha_xpl] xPL Hal in a loop


>
> It's tricky.
>
> I would have expected an X10 status message to be used to report the
state
> of an X10 device itself (via a status request of an X10 device that
supports
> it), whereas the X10.confirm is merely reporting that the CM12 has
sent
the
> message down the powerline.
>
> The built in support for X10 in xPLHal is surely there to aid the user
in
> setting up useful scripts - i.e. to avoid having to write real code
> themselves (hence the wizard).  If that's a goal, it doesn't make
sense
that
> they shouldn't have to filter X10.confirm messages themselves.
>
> I actually wonder whether the x10.confirm message is even necessary.
After
> all, it only reports whether the message was put on the powerline, not
> whether the X10 device reacted to it (impossible to know anyway since
status
> request is missing from most X10 devices).
>
> If confirmation is deemed necessary, then why not support confirmation
of
> any xPL message in a generic way, rather than by inventing special
> modifications for each schema.  This could be done by adding xpl-cnfm
as a
> message type like xpl-stat, xpl-cmnd, and xpl-trig.  It would just
echo
back
> the contents of the received message (i.e. the same schema).  It would
not
> be mandatory for a service to confirm messages, but the specification
would
> be there for those that wanted to do it, with no chance that they
would be
> mistaken for something else.
>
> Mal
>
>
>
>
>
>
>
> ----- Original Message -----
> From: "Tony Tofts" <tony@xxxxxxx>
> To: <ukha_xpl@xxxxxxx>
> Sent: Wednesday, September 08, 2004 5:47 AM
> Subject: RE: [ukha_xpl] xPL Hal in a loop
>
>
> > > The above script should only fire when B2 is actually
> > > switched on - not in response to a confirmation message, and
> > > it shouldn't be up to the user to check the schema
themselves.
> >
> > Hi Guys,
> >
> > I can't really agree here.
> >
> > There are 3 types of event (status, trigger, command) and the
particular
> > event called is controlled by this type.
> >
> > Even though x10 is built-in, it should be treated no differently
to any
> > other schema. If we start putting in exceptions for this, we'll
set a
> > precedent to start hardcoding exceptions for other schemas? Which
to me
> > seems to defeat the point of the scripting system.
> >
> > If anything it seems to indicate that x10.confirm should be a
status
> rather
> > than a trigger?
> >
> > Thoughts?
> >
> > Many thanks
> > Tony
> >
> >
> >
> >
> > 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
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
>
>
>
>
> 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
> Yahoo! Groups Links
>
>
>
>
>
>
>