[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: Schema for configuration
On Fri, 28 Oct 2005 20:04:03 +0100, Simon McCaughey
<simonmcc@xxxxxxx> wrote:
>> One thing I think a few of us do is to send out .Info class
messages
>> when queried directly, or on an intermittent basis. e.g. "I'm
>> currently playing this song." But we also send out .Event
class
>> <Snip>
>
> Yip, that sounds like the ticket, I can probably use events and Info
>messages to do all my inter process comms.
Here's a segment of the schema I use for the RedRat IR transceiver
connector. You might, for example, send a RedRat.Query message of
Class RedRat.Control, and in response a message of Class
RedRat.Control.Info is sent. This would be targetted back to the
original requestor.
Class = RedRat.Control
RedRat.Query
{
}
Class=RedRat.Control.Info
RedRat.Info
{
Name=
Desc=
Serial=
Firmware=
Company=
}
RedRat.Version
{
Major=
Minor=
}
In another example, you might want to change the state of the IR
detector on the RedRat device using the RedRat.Control class of
message. Messages of Class RedRat.Control.Event are sent out whenever
the IR detector on the RedRat has its status changed.
Class = RedRat.Control
IR.Detector
{
Enable=[ Yes No ]
-- mandatory
}
Class=RedRat.Control.Event
Detector.Event
{
Enabled=[ Yes No ]
-- mandatory
}
Another example I find quite interesting (others may disagree!) is the
OSD schema. Say I send several messages of this Class to display
around the house.
Class=Message.Display
Display.Text
--- mandatory section
{
Line1=(text to display)
--- mandatory
Line2=(text to display)
--- optional
:
LineX=(text to display)
--- optional and repeatable where X is a sequential number
Priority=(1 to 9, 9 being lowest)
--- mandatory
Duration=(seconds to display)
--- optional
Type=[Queue Immediate Permanent]
--- optional (Queue assumed, Permanent causes Duration to be ignored)
}
Applications such as the SlimServerConnector and MCxAP will queue
messages up such that they each get their own display slot without
overlapping each other. As a result when a message DOES get displayed,
I send a message of Class Message.Display.Info. This includes the
original Display.Text message block. Looking at it just now I wonder
if this really ought to be a Message.Display.Event class of message
though.
Anyway, I essentially re-use the parent class of message but by
sending out a Message.Display.Info or Message.Display.Event class
message I can avoid having it re-displayed but retain the exact same
message body content with a different meaning.
Oh, and to finalise things, when the display event is completed after
its slot of 30s or whatever I send a Message.Display.Event to signify
the end of the message.
Included in this message body is an extra block specific only to
Class=Message.Display.Event. When a display button is selected (in an
interactive display unit for instance), a response is sent, targetted
back at the original message sender.
Class=Message.Display.Event
Display.Response
{
Button=<button text selected>
--- mandatory (this value may be TimedOut if no response was selected
before the popup message duration expired)
}
HT-long-winded-example-H,
S
--
Stuart Booth <stuart@xxxxxxx>
xAPFramework.NET - a xAP software development framework for .NET
http://www.xapautomation.org/
http://www.xapframework.net/
xAP_Automation Main Index |
xAP_Automation Thread Index |
xAP_Automation Home |
Archives Home
|