[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Spec revisions...
- Subject: Spec revisions...
- From: Patrick Lidstone
- Date: Wed, 26 Mar 2003 09:38:00 +0000
A couple of thoughts to toss about re. the current version of the
spec.
1. Event based addressing
I've mooted this before, and although I know the (apparent)
complexity of current addressing schemes is contentious, I still find
myself wishing we could do "event addressing" as well.
At the moment, senders and receivers use schema which identify
functionality which is specific to the device. The idea of event
addressing is the introduction of -abstract- events which are not
tied to a specific device(s), but indicate a generic, system wide
change of status. Unlike source or target addressing, where messages
are one-to-many or many-to-one, events are many-to-many in the sense
that many devices can originate them and many devices can act on
them. Individual devices are free to act on the event or not as they
choose. Crucially, unlike the situation today, they do not need to be
explicitly configured to have a relationship with another device.
Examples might include an "audio.mute" event to silence devices
(perhaps with a message body which specifies the duration of
silence), or "occupancy.detection".
Whilst events could be used for group addressing too, that isn't
their primary purpose, and I suspect group membership probably needs
different semantics to allow for dynamic membership.
2. Heartbeats, devices and sub-addressing.
There is a case to be made for devices being able to support multiple
source or target addresses if they choose. Some pieces of hardware
may be able to support multiple logical functions that are totally
unrelated (e.g. Ian B's relay control, which is also capable of input
switch sensing, my rabbit board which can support two completely
different serial devices concurrently). The fact that these two
functions happen to be implemented on the same device is complete co-
incidence, and they really should be independently addressed. We
don't currently allow for that in the spec, and I think we should.
There is no issue for small devices here - we aren't doing away with
subaddressing, we're just saying that a larger device could support
multiple, independent source & target addresses. Such a device
would
also need to generate one heartbeat for each "core" address it
supported.
Thoughts?
Patrick
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|