Libraries pattern

A library is a versioned set of subroutines imported by client mixes. The version of the library can be identified using keys.

In the example in Table 1, the client mix chooses one of the two versioned subroutines using a key.

Table 1. svc_subr - Libraries
Example Description
<!-- CLIENT SIDE -->
<service name="ISR" provision="subr">  
  <prop name="subr.import" 
  user="ios@cisco.com" 
  key="v3.2"/>
</service>   
...
<request name="Router1Version" 
  service="ISR" 
  fields="SOME_FIELD">  
  <prop name="subr.spec" 
    function="GetVersion" 
    ancestor="isr4453" 
    Version="router1_version"/>  
  <reply name="Ok" 
    fields="router1_version"/>
</request>    
...
<!-- SERVER SIDE -->
<service name="Subr3.2" 
  provision="subr">  
  <prop name="subr.export" 
    key="v3.2"/>
</service>  
<service name="Subr3.3" 
  provision="subr">  
  <prop name="subr.export" 
    key="v3.3"/>
</service>  
...
<folder name="isr4453">    
  <solicit name="GetVersion" 
    service="Sequencer" 
    clients="Subr3.2 Subr3.3" 
    fields="GET_VERSION ISR4453">    
    <prop name="subr.spec" 
      function="GetVersion" 
      Version="version"/>    
    <response name="Ok" 
      fields="version"/>  
  </solicit>  
</folder>
...
This example uses a Modules pattern, in that a key-based matching is established between:
  • ISR, the service that supports the Router1Version operation
  • Subr3.2, one of the two client services that can fire the subroutine solicit, GetVersion

The solicit itself is the same in the two exported versions of the library, 3.2 and 3.3.

The ISR service imports only version 3.2.

The subr.spec property in both operations specifies the GetVersion function and binds the fields router1_version and version to the parameter Version.

The ancestor attribute is used as an additional selector, to pick the router model.

Important: A user can only import another user's SPARKL resources if he has execute rights.