41 lines
1.6 KiB
Plaintext
41 lines
1.6 KiB
Plaintext
|
|
||
|
Inter-machine protocols and object definitions for Build Console 1.0
|
||
|
|
||
|
UI-to-mtscript protocol:
|
||
|
------------------------
|
||
|
|
||
|
There are 3 rules that must be followed when communicating from the UI to
|
||
|
the mtscript engine, or from the master mtscript to slaves:
|
||
|
|
||
|
1) All info in the PublicData property is read-only on the UI.
|
||
|
|
||
|
-- It is technically possible for the UI to modify data in the
|
||
|
PublicData property, and there is no way to prevent this.
|
||
|
However, the UI should never take advantage of this. The reason
|
||
|
is that it is too easy for the UI to set data into that object
|
||
|
which is an interface remoted across the wire, and if the UI
|
||
|
goes away or is disconnected the data will no longer be available.
|
||
|
|
||
|
2) All commands and data sent from the UI to the mtscript engine are
|
||
|
done using the Exec() method.
|
||
|
|
||
|
-- This is an extension of rule #1.
|
||
|
|
||
|
3) ScriptNotify events fired by the mtscript engine should always
|
||
|
satisfy one or more of the following conditions:
|
||
|
|
||
|
a) The event is a notification indicating an interesting change
|
||
|
has been made to data in the PublicData property. The
|
||
|
parameters to the event may indicate more specifically what
|
||
|
data changed.
|
||
|
|
||
|
b) The event is a notification that is only meaningful at the time
|
||
|
of the event.
|
||
|
|
||
|
* Essentially, the event should never contain information that
|
||
|
cannot be recovered later if no client is connected at the time
|
||
|
the event is fired. This allows clients to connect and disconnect
|
||
|
at any point. Events are not queued if no client is connected.
|
||
|
|
||
|
|