Author: derek Date: Thu Sep 21 22:54:30 2006 New Revision: 112 Added: sofaswitch/trunk/callflow/docs/forloop.png (contents, props changed) sofaswitch/trunk/callflow/docs/overview.dxy Log: Add these files, as we now use a documentation directory. Added: sofaswitch/trunk/callflow/docs/forloop.png ============================================================================== Binary file. No diff available. Added: sofaswitch/trunk/callflow/docs/overview.dxy ============================================================================== --- (empty file) +++ sofaswitch/trunk/callflow/docs/overview.dxy Thu Sep 21 22:54:30 2006 @@ -0,0 +1,66 @@ +/*! \mainpage CallFlow - SofaSwitch control script generator + + +\section introduction Introduction + + This is an Open Source application specifically designed + to ease the development of call control in the SofaSwitch suite + of applications. + + The code is based on wxWidgets (for portability), in C++ (for + functionality and ease of integrating with exWidgets) and has + been released under the MPL license. + +Last updated 15 September 2006 + +Copyright (C) 2006 Indranet Technologies Ltd, All right reserved + +\section WhyCallFlow Why do we neeed CallFlow ? +My (DJS) initial thoughts on the design of SofaSwitch was that there would +be individual entities (server, voip, am etc) all controlled by a custom +script, written in some scripting language. I wrote the entities first, and +then wrote simple python scripts to test the entities. + +The python scripts started to grow quite large. Along the way, I altered the +control protocol, as I realised that there were some aspects missing from the +original design. This had the unfortunate outcome of making those scripts +invalid. A second lesson was learnt - python is not very good on +threads. Things like the global interpreter lock started to get in the +way. python script. + +At this stage, I was uncertain. Should I change to a different (and more +superior) scripting language? Some thought and discussion showed that python +is the way to go. Choosing an unknonw (but superior?) language like XYZ would +indeed solve the above problems, but introduce two new problems: 1)it is now +much harder to get get going in the project and 2)it becomes much harder to +install sofaswitch. Minor considerations such as, "we might loose +cross-platform features if we switch to XYZ" were part of the problem space. + +Clearly, the way ahead was to write a custom utility to write the python +controlscripts. Now, we expect that some may wish to write their own python +scripts. This is fine - you are welcome to learn from our current +codebase. Given the modular structure of SofaSwitch, this is +inevitable. Different modules will be glued together in different ways. + +Thus, the design of CallFlow was such that you can create scripts to do very +complex things with the minimum of effort. + +\section WhatDo What does CallFlow do ? +In this section, I describe, in overview, what CallFlow does + +\li Draw the diagram of the call handling for one call +\li Compile this to python, which creates two files. The first file + describes the graph, and the second file describes the handling of + the graph. The second file is "hardwired" to load that particular + graph file. However, the second file is is, essentially, the same between + every compile. +\li You use Python to execute the second file, which loads the graph file. + + + +\subsection history History + +\li 15 September 2006 - Created by Derek J Smithies +\li 21 September 2006 - Add Why section Derek J Smithies + +*/