Widgets pattern

Widgets are identical subroutines distinguished by their position in the configuration tree.

In the example in Table 1, there are two request/reply operations that call on two identical solicit/response operations. The requests use the solicits' position to call only one of the subroutines.

Table 1. svc_subr - Widgets
Example Description
<service name="Waiter" 
  provision="subr"/>
  ...
  <request name="GetBeer" 
    fields="GET" 
    service="Waiter">
    <prop name="subr.spec" 
      function="FunBeer" 
      Order="GET" 
      Beer="beer" 
      ancestor="Alcoholic"/>
    <reply name="Ok" 
      fields="beer"/>
  </request>

  ...

  <folder name="Alcoholic">
    ...
    <solicit name="Order" 
      service="Sequencer" 
      fields="ORDER" 
      clients="Waiter">
      <prop name="subr.spec" 
        function="FunBeer" 
        Order="GET" 
        Beer="drink"/>
      <response name="Ok" 
        fields="drink"/>
    </solicit>
    ...  
  </folder>

  <folder name="NonAlcoholic">
    ...     
    <solicit name="Order" 
      service="Sequencer" 
      fields="ORDER" 
      clients="Waiter">
      <prop name="subr.spec" 
        function="FunBeer" 
        Order="GET" 
        Beer="drink"/>
      <response name="Ok" 
        fields="drink"/>
    </solicit>
    ...
  </folder>
The request/reply operations both specify:
  • The same function, FunBeer
  • The same parameters, Order and Beer
In effect they could call either solicit/response as:
  • The response names match the reply names
  • The solicits and the requests are on the same service, Subr
  • The solicits specify the same function and parameters as the request/replies
  • The parameters are mapped to fields of the same type
    Note: ORDER and GET are flag fields, guinness, buckler and beer are strings.

The only distinction between the two solicits is a folder that exists somewhere above them.

The ancestor attribute in either request/reply uses these folder names to differentiate between the two solicits.
Tip: Since a mix counts as a folder, it can also be used as a value for the ancestor attribute.
Due to the ancestor attribute;
  • The GetAlcoholicBeer request calls on the GetBeer solicit inside the Alcoholic folder
  • The GetNonAlcoholicBeer request calls on the GetBeer solicit inside the NonAlcoholic folder
Note: Without the ancestor attribute the requests would randomly call either of the identical solicit subroutines, but only one of them, as opposed to multicast notify subroutines.

In either mix containing the solicits, there can be any number of different operations that help Sequencer collect the fields expected by the responses.