aMSN2 Basics

Draft 2
August 18th, 2006

Author: Harry Vennik


The aim of the aMSN2 project is to develop a successor of the current aMSN on a totally new codebase, using open standards and technologies where possible. The aMSN2 project is *not* to be a project separate of aMSN, but rather it is a sub-project of aMSN, that will take care of the longterm future. The current codebase is also being restructured a little to keep aMSN alive while aMSN2 is in the works. Seems like a bit of double work, but there is no other way to both create a stable aMSN 1.0 on the short term, and also create a beautiful aMSN 2.0 in the less near future. AMSN2 will not in any way retain compatibility with the current aMSN.

In aMSN2 we do not want to loose any features that are currently in aMSN, but still some parts may be discontinued. They will either have a replacement provided by anything aMSN2 will depend on, or there will be a replacement inside aMSN that will make our users forget the original in just a few minutes.

A big problem with the current aMSN is that its user interface is built with Tk, which is a toolkit so ugly that it really hurts your eyes, and it simply won't blend with the native look of any desktop. Currently this issue has been worked-around partially with the skins support and the Chameleon plugin, this will apply for all aMSN versions using the current codebase. In aMSN2 we will finally really solve the problem, and kick Tk out.

Another problem with the current aMSN codebase is its lack of modularity. In aMSN2 we will do our utmost to provide a set of modules with as little interdependencies as possible.



THE AMSN RUNTIME
The start-up file of aMSN2 will be the amsn executable file, which will provide an extended TCL runtime. This runtime is based on the normal TCL library, so the interpreter itself is not implemented in the amsn executable.

The executable will include:
- some start up code
- configuration management functions
- module loading/unloading functions
- event handling functions
- a general message logging system (which can be used from TCL code to implement status log / protocol log / etc.).

The start up code will just register the special TCL commands provided by the executable and then launch the core module called 'Main' using the module loading function.

The configuration management functions provide a standard way for all modules to store and retrieve their settings. Each module will have its own configuration domain, and have access to the global configuration domain. For plugins, the access to the global configuration will be read-only.

The module management functions provide a way to launch a module and to stop it again. Modules are in fact TCL programs on their own. To start a module, a new TCL interpreter instance is created, the module configuration is loaded, and the main TCL file of the module is sourced in the new interpreter. When a module is stopped, it will receive an event, to which it should respond by stopping execution as soon as possible. If it does not stop within a certain time limit, it will be terminated abruptly.

The event handling functions provide a way to fire events and to handle them. An event is registered on a per-module basis. So if an event is registered by module A, module B cannot fire that event. However, B may register an event with the same name, and fire that one. By default, events are local, but they may be registered as core or global. A global event can still be fired only by the module that registered it, but, contrary to local events, handlers for a global event can be registered from all modules. Core events are very much like global events: the only difference is that core events are not visible to plugins. Plugins can only register local events, and handlers for local and global events.

The logging system will provide a way to register loggers, and write messages to a log. The way it works is very simple. After a logger is registered, any message written to that logger will raise an event. The module that registered the logger will handle that event, and thus receive the message, and then do with it whatever it likes (display it on the screen and/or store it to a file most likely). The log event will always be local to the module that registered the logger, but messages can be written to a logger from any module.


TCL COMMANDS PROVIDED BY THE RUNTIME
All commands are registered in the namespace 'amsn'.
Here is a list of the commands. I think they are quite self-explanatory.

1. Load/Unload core module

load $module_name
unload $module_name

1. Load/Unload plug-in

load plugin $plugin_name
unload plugin $plugin_name

1. Configuration

config set ?global? $key $value
config get ?global? $key $value

1. Logging

log register $log_name
log write $log_name $message ?$severity?

1. Events

event $event_name ?{local|core|global}?
fire $event_name ?...?
handler $event_name $proc_name
handler delete $event_name $proc_name


Notes:
- To register a handler for a global event registered by another module, prepend the module name and a dot to the event name. So if module B wants to listen for a global event 'something_happened' registered by module A, then B would need to register a handler for event 'A.something_happened'. Of course event names themselves may not contain dots.

- The event name 'log_new_message' is reserved for use by the logging functions. The handler proc for this event will receive the log_name as its first argument, the message as the second argument and the severity as the third argument. Severity is either 'notice', 'warning', 'error' or 'critical'. The log handler may use the severity parameter to determine how the log message should appear in the log file and/or on the screen.

- When writing messages to a log, use the appropriate severity. The default is 'notice'. The 'critical' severity should only be used if the error being logged is so severe that the module writing the message will need to stop running.

- Log names are global. If two modules try to register the same log name, the second gets an error.


DBUS-TCL BINDINGS
Because aMSN2 will use Telepathy, it will need D-BUS. And because aMSN2 will be written mostly in TCL, it will thus need TCL bindings for D-BUS. These do not exist yet, so we will need to implement those. The Python bindings for D-BUS may serve as an example on implementing D-BUS bindings for an untyped language. For TCL things will be a little more complex however, because TCL has no built-in support for OOP.


TELEPATHY AND LIBMSN
In fact aMSN2 will just be a Telepathy-compliant IM client with support for MSN-specific Telepathy extensions. These MSN-specific Telepathy extensions are not defined yet, and will be defined in co-operation with the Telepathy team. Thus they will become a standard for all Telepathy Connection Managers for the MSN protocol.

Our own Connection Manager will be implemented according to the design by Roelof Kemp, and will use our libmsn (which is currently being implemented by Roelof) for the MSN protocol stuff.

The Telepathy client side will be implemented in one of the aMSN2 core modules, using the D-BUS bindings for TCL.


FARSIGHT
To support audio and video streams, aMSN2 will also use Farsight. For this to work, we may need to implement TCL bindings for Farsight. It may also be so that libmsn will handle that stuff, and we can thus use Farsight directly from C. This will also depend on what the MSN specific extensions to Telepathy will look like.


CROSS-PLATFORM GUI
This is probably the most wild plan for aMSN2: a GUI that uses native widgets on all supported platforms. For aMSN2, the platforms planned to be supported are: Linux (with GTK+ or Qt toolkit), MacOSX and Windows.

This means that we may need a generalized GUI toolkit that is implemented using native widgets on each platform. Until now there seems to be one such toolkit: wxWidgets. We can either use that, or implement our own cross-platform toolkit. The pro for wxWidgets is that is will save us a lot of work, the con is that it is written in C++. See also: http://www.wxwidgets.org/

Apart from the toolkit, we also had the idea to have the GUI be described in XML. For this we'll need to establish some tag set and formalize that into an XML schema to make validation possible. Then of course the XML should be mapped to widgets. This can be done either by mapping to a cross-platform GUI toolkit that is implemented using native widgets (e.g. wxWidgets), or by mapping directly to native widgets (i.e. implement the mappings separately for all platforms, and thus eliminate the need of a full-blown cross-platform toolkit implementation).


amsn
|--- connmgr
|     |--- libmsn
|     |     `--- (any libmsn files)
|     |
|     `--- (any connection manager source files)
|
|--- core
|     |--- Main                 # The 'Main' module
|     |     |--- modStart.tcl   # Module start-up code
|     |     `--- (any files this needs)
|     |
|     `--- (any other modules)
|
|--- lib                        # Any TCL extension packages (either in C or TCL)
|     |--- dbus-tcl             # TCL bindings for D-BUS
|     |     |--- pkgIndex.tcl
|     |     `--- (any files this needs)
|     |
|     |--- runtime              # Implementation of the runtime functions
|     |     |--- confmgr.c
|     |     |--- events.c
|     |     |--- init.c
|     |     |--- logs.c
|     |     |--- modules.c
|     |     `--- (any files this needs)
|     |
|     `--- (any other packages)
|
|--- plugins
|     `--- (any plugins)
|
`--- amsn.c                     # Runtime start-up code


There is no pkgIndex.tcl in amsn/lib/runtime because the runtime does not need to be loaded as a TCL package. It is just linked together with amsn.c into one executable.

So far we have the following external dependencies for aMSN2:
- D-BUS
- Farsight
- GLib
- TCL
- Telepathy