Up to [Platon] / libco

update [TODO]

::: NEAR FUTURE :::

CLONE [target: 0.2.3, done: 40%]
This should replace current constructor approach. There will be constructor,
but only as a prototype creation mechanizm, and it will be autogenerated by
copp. It will set up message-handler table for the object and so on.
More types of cloning should be available: shallow copy, deep copy,
stand-alone, etc. This will then affect way objects are coupled - as with
default, method tables are shared - and thus adding (or removing) method at
runtime will affect all such objects. Stand-alone cloning will create new
method table and thus new object group.

NEW OBJECT STORAGE [target: 0.2.3, done: 90%]
Object is stored as type + message pointer + data pointer + extensions.
Message pointer is called directly (no destroy handling or alike). Data
pointer is self-explantory. The extensions are provided for things like events
or method tables. You can stuff as much things as you like there, but this is
static -- you must know size when object is constructed and it can't be
changed. You might use this for data if you like, but you will have to write
your own constructor for this object (and maybe make other precautions --
which means this is nothing but hassle).

NEW MESSAGE SENDING APPARATUS [target: 0.2.3, done: 90%]
No care is taken from the message sending function (co_m, co_m_v), it only
passes the arguments to message handler. This message handler should come from
an extension, which uses the extension area of object to store its
administration (method table or deferred universal message handler).

NEW OBJECT DELETION METHOD [target: 0.2.3, done: 60%]
Objects will be deleted by simply sending "delete" message with no parameters.
Delete method of an object shalt send "destroy" to itself or defer this action
until object is unused. May take other precautions. Shalt be safe to send from
anywhere (asynchronous thread or method of same object). Destroy retains it
previous meaning - do not call! Also, destroy should now call appropriate
extenstion cleanup function (like co_ev_destroy).

NEW BLESSING SCHEME [target: 0.2.3, done: 60%]
Each object type has these crucial components: flavour (with it's creation
function) and bless (initialising flavour-specific data and object's data
pointer). The flavour initialisation is provided by it's implementation.

COPP REWRITE [target: 0.2.3, done: 40%]
The copp preprocessor shalt be rewritten, using sensible framework (like
iotta ;]). Also, it should separate different parts into different modules,
allow selecting features for each run (like python-wrappers-only or
object-support only), support object flavours et cetera.

::: DISTANT FUTURE :::

MORE INTELLIGENT CO_METH_INI [target: 0.2.x, done: 0%]
These should not need explicit object name, just get it from last CO_OBJECT or
CO_METH respectively. The CO_METH problem is much harder to solve and also a
bit more annoying.

REFLEXION [target: 0.2.4, done: 40%]
A method should be available for each object that will provide outside world
with informations from method table of object. By means of copp it should be
incorporated in message table of every prototype object.

PLUGIN ARCHITECTURE [target: 0.2.5, done: 50%]
Create consistent framework built on libltdl for loading modules. Each module
shalt become object in loading process and export its interface this way.

AUTOMATIC PYTHON BINDINGS [target: 0.2.6, done: 30%]
All co objects should be import'able and instantiable from python. Also, their
methods should be accessible through default pythonish interface (eg a.test
("blee") should send message "test" to object "a" with string argument
"blee"). And they should be buildable separately from rest of library, so they
don't drag python dependency into all libco-using projects. Like
libco-python.so.

SECURITY [target: 0.3.1, done: 0%]
Fix buffer overflows and alike.

INTO - INTERFACE OBJECT PROTOCOL [target: 0.3.x, done: 0%]
Protocol and support infrastructure for program visualisation independent of
interface. Should use IGLUE modules - interface glue - for each interface
type. Program written with INTO support should support all interfaces for
which IGLUE modules are available.

DATABASE SUPPORT MODULE [target: 0.3.x, done: 0%]
Database independent inetrface with postgresql as reference platform.

CO_MAP ASSOCIATIVE ARRAY [target 0.3.2, done: 0%]
CO_BTREE BINARY TREE IMPL [target: 0.3.5, done: 0%]
THREAD SUPPORT [target: 0.4.x, done: 0%]

::: DONE :::

MESSAGE TABLE CREATION [target: 0.2.1, done: 100%]
TABLE-DRIVEN DEFAULT MSG HANDLER [target: 0.2.2, done: 100%]
At least for now it should use simple cycle comparing received message id with
method table items one by one. When found, method shalt be executed, if not,
default action taken (i.e. "default" method invoked, which then could take
care of implicit delegation et cetera).

MORE INTELLIGENT CO_ATTR [target: 0.2.2, done: 100%]

SEPARATE MESSAGE EXCEPTION STACK [target: 0.2.3, done: 100%]
The co_m_v should use separate stack, so cox_push/cox_pop pairs can cross
message boundaries (eg. message returning unpopped value)...