Author: derek Date: Mon Nov 13 22:17:24 2006 New Revision: 193 Added: sofaswitch/trunk/callflow/docs/current/Eventer.png (contents, props changed) Removed: sofaswitch/trunk/callflow/docs/current/eventer.png Modified: sofaswitch/trunk/callflow/docs/current/eachicon.dxy Log: Rename eventer to Eventer, which removes confusion with the one of the name eventer.png in the bitmaps directory. Added: sofaswitch/trunk/callflow/docs/current/Eventer.png ============================================================================== Binary file. No diff available. Modified: sofaswitch/trunk/callflow/docs/current/eachicon.dxy ============================================================================== --- sofaswitch/trunk/callflow/docs/current/eachicon.dxy (original) +++ sofaswitch/trunk/callflow/docs/current/eachicon.dxy Mon Nov 13 22:17:24 2006 @@ -7,21 +7,41 @@ how one would use each structure within a call flow diagram. \subsection subsecStartFlow Initiate graph processing +Start of graph processing is indicated by the toolbar icon and drawing area +image of +<CENTER><TABLE frame=void border=0><TR><TD> +\image html Controlsstart.png +</TD><TD> +           +</TD><TD> +\image html startflow.png +</TD></TR> +</TABLE></CENTER> -The toolbar icon \image html Controlsstart.png -is used to indicate that the user wishes to place the "Initiate graph -processing" item on the screen, which looks like: -\image html startflow.png "Initiate graph processing" +When this graph is processed, this item indicates that a new identity on the +server will be created, for each item on this graph to communicate with. Thus, +on instantiation, this graph will be identified as identity \c c290 (say). Any +messages sent via the server will be labelled as being sent by \c c290. + It is mandatory that there is only one of these items on each graph. Placing -more than 1 item is ambiguous - where would call processing start ? +more than Start of graph processing item on the drawing area is ambiguous - +where would call processing start ? +\subsection subsecJoinObjects Join items on the drawing area +The toolbar icon and a possible rendering of a drawing area shape is shown below. +<CENTER><TABLE frame=void border=0><TR><TD> +\image html JoinObjects.png +</TD><TD> +           +</TD><TD> +\image html joinlines.png +</TD></TR> +</TABLE></CENTER> -\subsection subsecJoinObjects Join objects on the drawing area - -The toolbar icon, \image html JoinObjects.png -indicates a user drawn multiline segment object that connects objects. +Items on the drawing screen may be joined directly - one to another, or joined +with this structure, which is multiline segment object. Select the toolbar icon, move to the drawing area, and left click to mark the points on the shape and complete with the right mouse button. Once completed, you may move the shape by selecting it with the left button @@ -31,22 +51,111 @@ circle is drawn at each end. It is entirely valid to have the output of several items connected to one -item. Thus, the following shape is valid, +item. Thus, of the the following two shapes, the left is valid, -\image html validjoinexample.png "Valid use of the join objects structure" +<CENTER><TABLE frame=void border=0><TR><TD> +\image html validjoinexample.png +</TD><TD> +           +</TD><TD> +\image html faultyjoinexample.png +</TD></TR> +</TABLE></CENTER> -and this shape is invalid. -\image html faultyjoinexample.png "Incorrect use - the graph is ambiguous" - -The invalid shape is ambiguous - it is not clear where the flow of execution -should go. In this example, I suppose, it would "work", in that there is no +and the right shape is wrong. The key problem with the right shape is that it +is ambiguous, since it is not clear where the flow of execution +should go. In this example, it would "work", in that there is no difference if either path is followed. +\subsection subsecRequestNode Request Node +The toolbar icon and a rendering of a drawing area shape for the "Request Node" +item is shown below. +<CENTER><TABLE frame=void border=0><TR><TD> +\image html RequestNode.png +</TD><TD> +           +</TD><TD> +\image html requestnode.png +</TD></TR> +</TABLE></CENTER> +Request Node is a key component of the SofaSwitch suite of applications. With +this item, the controller asks the designated application to supply one worker +node for use by this call graph. Alternatively, this is the mechanism by which +this call graph gets remote entities who can handle media data. +Once created, the requested worker has a lifetime of 2 seconds. This lifetime is +set by the designated application. If the requested worker is not acknowledged +after 2 seconds, it is destroyed by the designated application. +On receiving advise the node has been created, and its identity, this call +graph can advise the node to "transfer media to itself". Once this command is +made, the requested node is safe from death by timeout. + +The Right Mouse Button on this request node shape brings up a menu box. You +may adjust the Tool Tip accordingly - I prefer to change this to indicate +who/what I am requesting a node from. The timer period here is a float, which +indicates how many seconds we will wait for a reply. The timer which runs is +labelled by the above string, which is used in the comparison of an eventer +box \ref subsecEventer. The additional information field is used to provide +details that some SofaSwitch applications want. For example, the conference +utility needs information on which room the node should be in. + +\subsection subsecEventer Event Collection +The toolbar icon and a rendering of a drawing area shape for the "Event Collection" +item is shown below. +<CENTER><TABLE frame=void border=0><TR><TD> +\image html bitmaps/eventer.png +</TD><TD> +           +</TD><TD> +\image html current/eventer.png +</TD></TR> +</TABLE></CENTER> + +Event Collection is the central to the processing of each graph. With this +item, we have made it possible for the system to respond to network and timer +events. Alternatively, the primary purpose of this structure is to provide a +general means of registering to receive an event. + +In our implementation, events are collected in the background, and then +processed after execution has fallen into a "End Processing" box, which is +described in \ref subsecEndProcessing. + +The Event collection item has two outputs. + \li On the right, which is where execution goes after registering for an + event. + \li On the bottom, which is where execution returns to after detecting the + event. + +Clicking the right mouse button brings up an edit box, where you control what +events are sought for. The Tool Tip is as before. The particular event you are +seeking to match on is specified with Python code, or as a Python regular +expression. It is an error to specify both methods. + +A Python variable is initialised to None when this item is entered from the +top. This variable is specified in the edit box, generated by the right mouse +button. To illustrate, after a DTMF event, the Python variable will hold the +particular DTMF value that was detected. + + +\subsection subsecEndProcessing End Graph Processing +The toolbar icon and a rendering of a drawing area shape for the "End Graph Processing" +item is shown below. +<CENTER><TABLE frame=void border=0><TR><TD> +\image html bitmaps/ControlsEndHere.png +</TD><TD> +           +</TD><TD> +\image html current/endflow.png +</TD></TR> +</TABLE></CENTER> + +This icon is provided as a means for temporarily holding up graph processing, +while we wait for external events. If processing does fall into here, external +events will move graph processing to an Event Collection item as required. */ \ No newline at end of file