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.
Example | Description |
---|---|
<folder name="Libraries"> <mix name="Client"> <service name="ISR" provision="subr"> <prop name="subr.import" key="v3.2" user="ios@cisco.com" /> </service> <request name="Router1Version" fields="SOME_FIELD" service="ISR"> <prop name="subr.spec" ancestor="isr4453" function="GetVersion"/> <reply name="Ok" fields="router1_version"> <prop name="params"><![CDATA[ version:router1_version ]]></prop> </reply> </request> </mix> <mix name="Mix"> <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" clients="Subr3.2 Subr3.3" fields="GET_VERSION ISR4453" service="Sequencer"> <prop name="subr.spec" function="GetVersion"/> <response name="Ok" fields="version"/> </solicit> </folder> </mix> </folder> |
This example uses a Modules pattern, in that a key-based matching is established
between:
The solicit itself is the same in the two exported versions of the library, 3.2 and 3.3. The The The Important: A
user can only import another user's SPARKL resources if he has
execute rights.
|