Mission Thoughts

Contents

Mission Thoughts

Don't import part of the tree
Discovery locates interface and retirns its OID
Interface imported
All communications done through interface
Interface
- events
- notifications
- operations

Interfaces cannot really be a domain because that exposes too much of the interface for the contained managed objects. Am Interface should broker the calls through it.

The InterfaceDescription is

Events that can be raised by the interface
Notifications (events) that can be sent into the interface
Operations that can be invoked using the interface

Currently

Events
- <list>to get the list of args for an event
Notifications
- <call> to invoke the event
Operations
- Performed by a <call> operation with parameters. The call is rewritten and passed on the the appropriate managed object

This means that you have to know when you are invoking something through the Interface.

Probably better to have the operations become part of the interfaces' operations but then they could clash with interface specific operations. Need to think about it

We are ok events?

Currently we have an operation on any Managed Object of

<event name="/event/blah">
  <arg1 />
  <arg2 />
</event>

The interface intercepts this call, rather than leaves it as the default, and rechannels it.

All the remote communications for all that we are talking comes for free, i.e. it is already included in Ponder2Comms.

XML Descriptions

Common
- CommonXml
Nurse
- NurseXmlDiscovery
- NurseXmlInterface
- NurseXmlMission The problem is Interface Substitution
Patient

Managed Object Descriptions

DiscoveryDescription

InterfaceDescription

MissionDescription

Problems

Interface Substitution

Normal XML

<use name="/some/name usearg1="" usearg2="">
  <operation1 op1arg1=""/>
  <operation2 op2arg1=""/>
</use>

We now have an OID which looks like

<oid stuff="" stuff1="">
  <morestuff />
  <morestuff1 />
  ...
  <laststuff />
</oid>

We want to use the following construct, where !patient; is an interface, it could be a path or OID. However the !patient;.endEGC is an OID.

<use name="!patient;">
  <startEGC/>
  <timer wait="!ECGTime;" event="!patient;.endEGC"/>
</use>

How do we give args and operations when we have only an OID? e.g. !interface;.op where interface is an OID.

We really need something like

<command>
  <use />
  <operation1 />
  <operation2 />
</command>

Therefore we can have

<command>
  <oid />
  <operation1 />
  <operation2 />
</command>

With useargs

<command usearg1="" usearg2="">
  <use name="foo"/>
  <operation1 ...>...</operation1>
  <operation2 ...>...</operation2>
</command>

The old form

<use >
  <operation />
</use>

could be a synonym for the example above. So, Managed Objects would be given the whole <command> structure and will parse it accordingly. Also wherever we have a <use> clause it can be directly replaced with an OID if we want.

Policies

Policies currently have < event="foo" > which will not work with OIDs nor interfaces. How do we resolve the interface event to an OID? Events are currently generated internally by Policies and other manged objects but they should use the general Managed Object interface. If we change the <event> operation to the following we can give a similar construct to the Policy to hold and use

<command>
  <use> or <oid> of managed object/interface
  <event name="foo">   <==== this would be needed by the interface and is horrible!!!!!!!!
    <use> or <oid> of event type  <==== maybe the interface could match the <use name=""> 
                                  or the <oid> to know what to do with it. It could tag its 
                                  own OID with something as the events' OID. --- Yes!!!!!!!
    <arg1 ... />
    <arg2 ... />
  </event>
</command>

In the Policy definition becomes

<command>
  <use name="/template/policy">
    <create active="true">
      <event>
        <use> or <oid> of event type
        <arg1 to be used by policy>
        <arg2 to be used by policy>
      </event
      <condition/>
      <action/>
    </create>
  </use>
</command>