The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

RE: Logger WAS Re: vendor ID reservation


  • Subject: RE: Logger WAS Re: vendor ID reservation
  • From: "Ian Lowe" <ian@xxxxxxxxxxxxxxxxxx>
  • Date: Wed, 15 Dec 2004 20:20:41 -0000



I'd say there's always value for some more toys!

On the more technical discussion items...

> Should a "rebroadcaster" resend the identical messages,
giving the
original sender as the > "source"? The side-effect of this is
that this
is tantamount to "message forging", which > may run into
issues in the
future

I think the middleground you suggest is where the current design
thinking would go -

To work best, xpl-cmnd messages should originate from the rebroadcaster
app - in a diagnostic/logging environment this will allow us to see who
sent the command - there's no issue here as xpl apps are required to
obey an xpl-cmnd message no matter who sent it on the network. Except
(of course, an exception) in one well defined case, where an app is
"locked" to a single commander for a sequence of messages such as
an OSD
menu built up line by line.

For the xpl-stat and xpl-trig messages, the original source should be
used - it's okay to send a message masquerading as another device within
the xPL context - we had a good think about this one early on, (as I
recall, in exactly this context!) and don't see it as such a big deal.

Ian.





xPL Main Index | xPL Thread Index | xPL Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.