::: 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)...