design rationale behind TaskContext

After having used it for some time now, I much appreciate the way in which the TaskContext has been designed and structured. It is also beautifully depicted in the figure at the bottom of e.g. the RTT frontpage.
Is there a document that details the design rationale behind it? That is, a report or so that describes the considerations that have been made, the pro's and con's of the resulting design (as you see it), ideas for further development, etc., rather than the (also useful!) usage/code oriented documentation that can be found on the website.

Cheers, Theo.

design rationale behind TaskContext

On Wed, 10 Dec 2008, t [dot] j [dot] a [dot] devries [..] ... wrote:

> After having used it for some time now, I much appreciate the way in
> which the TaskContext has been designed and structured. It is also
> beautifully depicted in the figure at the bottom of e.g. the RTT
> frontpage.
> Is there a document that details the design rationale behind it? That is,
> a report or so that describes the considerations that have been made, the
> pro's and con's of the resulting design (as you see it), ideas for
> further development, etc., rather than the (also useful!) usage/code
> oriented documentation that can be found on the website.
>

_the_ real reason for its design is not so much technical, but rather
"psychological": after some trials with other programming primitives, we
found this TaskContext concept a very good trade-off between complexity on
the one hand, and understandibility by our typical PhD students on the
other hand. The "complexity" aspect was very much inspired by the concept
of component-based programming, where the CORBA Component Model was the
major source of inspiration; the "understandibility" aspect was driven by
the need to hide distribution and (realtime!) IPC details from our PhD
students. Also maximal platform-independence and maximal decoupling were
major design priorities.

Personally, I am still rather quite happy with the TaskContext as
programming primitive, although we have already a whole roadmap/wishlist of
implementation and standardization issues that we would like to revise for
the 2.0 version...

Herman