Hi all,
Finally I found some time to document some of my ideas in more detail. The
result is this new draft. Quite a lot changed since the previous one, and it
will change again in the next drafts (at least on those places where it just
contains some vague suggestions). But I think things already are a lot better
and more clear now.
Any feedback is appreciated!
Harry
aMSN2 Basics
============
Draft 2
August 18th, 2006
Author: Harry Vennik
What aMSN2 is meant to be
-------------------------
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.
Technical Structure of aMSN2
----------------------------
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.
# Load/Unload core module
load $module_name
unload $module_name
# Load/Unload plug-in
load plugin $plugin_name
unload plugin $plugin_name
# Configuration
config set ?global? $key $value
config get ?global? $key $value
# Logging
log register $log_name
log write $log_name $message ?$severity?
# 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: 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).
Source Directory Structure
--------------------------
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.
Dependencies
------------
So far we have the following external dependencies for aMSN2:
- D-BUS
- Farsight
- GLib
- TCL
- Telepathy
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
