This file describe the problems or feeling we experienced while
developping a medium size application using tlmp. A mail program
is a fair example of a full feature GUI project.

Good things
===========

Ok, for the good things. After 1700 lines of tlmp code, we have a pretty
powerful mail program. Multi-document interface both for the viewer, the
composer and the browser. We have an address book, folder selector
and even logical folders, which are views of normal folder.

At this point, tlmpmail is still not usable. It does not update
folders yet and does not support MIME at all.

The major good feeling about it is that just by looking at mainmail.tlcc
you pretty much see everything about the program. You also has
pretty much all the hooks you need to enhance this program.

The major benefit of TLMP is that you think differently. You think
about featureful components where the caller can customise the usage
very easily. Your component has then default behavior, changeable
easily by the client. One may argue that C++ virtual function
deliver the same benefit. Yes an no

	-Yes, because tlcc file are turned into C++ files and the
	 logical function (the <f logical> tags) are translated to
	 virtual function.

	-no because achieving the same ease of use is not possible
	 without the glocal variables. You would end up with
	 classes which knows about each other and become less and less
	 reusable.

Issues
======

Passing information accross uithread could be easier

Is using uithread_id to differentiate various document information
(framework::document) a problem ?

Using uithread, execution order may be confusing. The new thread will
execute after the caller has called its own edit function again.
In general, we solve this by passing information to thread, allocated
by the callee and freed by the new thread. In tlmpmail, we often end up
with two new threads. The first is created by framework, which then call
the composer for example, which itself defines a new thread. It does
so to ease the composer usage. This make sure the composer is always
autonomous, related to its caller. So back with our first thread, this
one will terminate quite soon. This leads to the problem of who
is freeing the information. A solution to those problems is to
use reference count on the object. Not too bad, but cumbersome to manage.
Something easier is needed.

Sending signal (dialog_sendmessage()) seems to be a fairly confortable
mecanism for asynchronous dialog to exchange information. When implementing
the status line, we found that since dialog_sendmessage is asynchronous
it was not possible to set the status line, do a task and set with a
new message. Maybe we need two sendmessage, one which make sure all
related thread have respond and another which end immediatly, letting
the threads react later.