Messages are Events.
Messages require OOB information.
Tags are a kind of OOB infromation that influences how a Message is handled at it's various stages of propagation. Dealing with these tags will be hellish. Where are they defined? How long do they last? What do they mean? Should certain tags be inherited by sub-events, or not? What are the namespace rules for tags?
Colour is one type of tag. If we think of States as nodes, and of Messages as edges in the nodes, we get a graph of the propagation of messages through the system. That is, one Message will probably create more Messages when it invokes a State, which could then create even more Messages and so. If each Message has a Colour, we can trace it's influence throughout the system. And we can discover the edges of the graph that has same-colourd nodes.
Why is this useful?
We could designate the return values of all the edge States as the return value of the orignal Message and have it sent to some Destination. This would get rid of one of the uses of call(). It would also do away with IKC's post_respond() and all other forms of "post() but give me an answer sometime."
We now have an excelent place to hook in some exception handling.
We can deal with something that I call a Crossbar, which is sort of like a semaphore or a way point. That is, say a task requires 5 steps (A B C D E), A has to come first, E last, the others can happen concurrently. So A would post B, C, D. And E would wait until the coloured graphs from those 3 Messages would die.
We can "effortlessly" add timeouts to post-with-response and other situations.
If we want to, we could make the death of one colour wait for a new colour to die. This way we could auto-vivify IKC connections. All with the aformentioned timeouts.
Save this on Delicious