Resolver

From ago control wiki
(Difference between revisions)
Jump to: navigation, search
(ago resolver)
(ago resolver)
 
Line 1: Line 1:
 
= ago resolver =
 
= ago resolver =
While components in ago control can talk to each other without the resolver, this is the central piece that handles device "registrations" and does name resolving, so that you can set names for devices and check which devices are available. The resolver implements the "inventory" command. It will return an inventory containing a device list, a room list and the schema. It listens to different events to keep the inventory up to date:   
+
While components in ago control can talk to each other without the resolver, this is the central piece that handles device "registrations" and does name resolving, so that you can set names for devices and check which devices are available. Therefore it should be always running. The resolver implements the "inventory" command. It will return an inventory containing a device list, a room list and the schema. It listens to different events to keep the inventory up to date:   
 
* device announce
 
* device announce
 
* device removal
 
* device removal
Line 15: Line 15:
 
* setdevicename
 
* setdevicename
 
* deleteroom
 
* deleteroom
 
The resolver should be always running since it's the secound core near qpidd(AMQP). Start oder has to be qpidd, then agoresolver.service and after that all other devices.
 

Latest revision as of 22:29, 26 October 2012

[edit] ago resolver

While components in ago control can talk to each other without the resolver, this is the central piece that handles device "registrations" and does name resolving, so that you can set names for devices and check which devices are available. Therefore it should be always running. The resolver implements the "inventory" command. It will return an inventory containing a device list, a room list and the schema. It listens to different events to keep the inventory up to date:

  • device announce
  • device removal
  • state changed

The schema is provided, so that any party does know what other devices understand as command, or what fields are expected to be in events as eventparameter. It also holds descriptions for commands, so that a GUI can draw proper buttons for example.

one of the major concepts is that every part can be restarted without issues and that startup ordering is not important. So when the resolver starts after other devices or has to be restarted, it sends a "discover" command without any uuid - kind of a "broadcast command". Every other component that provides devices to the system, should react to this request and send device announce events for the devices it manages. While this behavior is optional, as components can talk to each other without resolver, it is strongly recommended as important parts like the user interfaces rely on the inventory.

The resolver also has a few special commands to set device names, set room names (and create rooms), and assign devices to rooms. This enriches the inventory so that user interfaces can provide the devices to users in a more friendly way:

  • setroomname
  • setdeviceroom
  • setdevicename
  • deleteroom
Personal tools