Remarks=======Note: this document is outdated.Code Organization-----------------I propose that all the C++ code developed for the project is placed in the namespace ambulant and further divided into packages using sub-namespaces. The GRiNS organization of the code was good enough and we should try keeping it but not blindly.Concerning dependencies, the code may be organized as a set of layers as shown below:Layer 0:Std C++ libraryNamespace: stdWe may need some Ambulant extensions to the std. These extensions may form various packages named according to their purpose. For example ambulant::net for networking related components. Foreign endorsed libraries may exist and should be used at this level.For Python people: These are the modules of python/lib.For Java people: These are the packages starting with the "java-dot" prefix.Layer 0 has nothing to do with Ambulant except that the projecthappens to need these general modules.Layer 1:Ambulant library. Namespace: ambulant::libMay depend on layer 0 packages.Layer 2:Ambulant commonNamespace: ambulant::commonMay depend on any of the layers below.Layer 3 (application layer):Ambulant playerNamespace: ambulantMay depend on any of the layers below.Exceptions and assertions-------------------------Assert usage is clean:  during development we use assert to check preconditionsand post conditions and it抯 a sort of documentation. For C and C++ it抯 a macro often disabled in not debug builds. Can be defined to do whatever. Its default implementation when it fails is to point out the condition, the line and the source file. I think we should use them extensively as a means for both testing and documentation. Concerning exceptions every language has its own semantics and culture for them. Exceptions are an integral part of the C++ standard. They are used at the correct weight in the STD C++ library. Having an exceptions mechanism it is important since it solves a recurring problem: a piece of code cannot do what it was asked for and no meaningful action can be taken locally. Somebody can always design custom solutions to solve this problem but having a standard mechanism is important.Though some C++ compilers (the old WinCE MS compiler for example) may not support exceptions I think that we should use them in our code. The mainstream compilers do support them and are part of the standard. If we choose not to use them then we will have to invent our own mechanism, which is not a so good idea. Using exceptions will make our code more clean, robust and easier to test. If it is needed and when it is needed a porting for compilers that do not support exceptions may be made.XML Parser----------Ambulant may use/support through a SAX plug-in interface the following XML parsers:1. Expat, James Clark抯 XML parser, lightweight (release dll size ~140KB), C implementation2. Xerces, Apache validating XML parser, complete but heavy (release dll size ~1.654KB), C++ implementation (rather a Java port)3. Msxml, Microsoft抯 validating XML parser, complete, heavy (release dll size ~1.230KB) but always present on windows platforms.Regex libraries---------------We may consider the following libraries for adding regex support to Ambulant:1. Philip Hazel's pcre, regular expression library, C implementation2. Henry Spencer's regular expression library, C implementation3. Regex++ from Boost, C++ implementation, a litle heavy (but it offers much)4. Greta from Microsoft, C++ implementationURL handling------------There is a lot of standard code we need to handle URLs, such as basejoins,converting file: urls to local pathnames, etc. We should look for an existing lightweight package for this, or roll our own.RTP/RTSP Library----------------We are going to need an RTP/RTSP library for transport, and the license is important.A quick search on the web came up with the following packages, which haven't yetbeen examined further:1. Live.com Streaming Media - RTP/RTSP, and also includes various codecs. LGPL License.    Fairly popular, according to themselves. Runs on Windows/Linux/MacOSX.   The website looks a bit clunky.2. Vovida.org - RTP/RTSP and much more. License looks BSD-like, but needs to be read   more carefully. This may not run on Windows out of the box.3. MPEG4IP - This looks pretty similar to Ambulant itself, but MPEG4-centered in stead   of SMIL-centered. Mainly linux, but "a crude windows port is available". Mozilla license.   The RTP library used is actually the UCL Common Media Library implementation.   I have seen no mention of RTSP here, nor on the UCL site, so we would need to check   that it actually has it.4. Open MASH - A framework for creating multimedia apps. Unix/Windows, BSD license.   Looks like it may be too tied to Tcl (they do lowlevel stuff in C/C++ and glue   everything together in Tcl).   A much longer list of implementations can be found at http://dmoz.org/Computers/Internet/Protocols/RTSP/Implementations/ .   Question: is there RTP/RTSP support builtin on win32/wince?