ipc.pdf ... some remarks (fwd)

The mail that I forward below is the beginning of a private email
exchange between Christian and myself, about the event and state
machine document. Christian succombed to my insisting to make this
discussion public :-) I will post the whole thread.

Herman

---------- Forwarded message ----------
Date: Thu, 20 Jun 2002 10:04:27 +0200
From: Christian Schlegel <[email protected]>
To: "[email protected]"
    <[email protected]>
Subject: ipc.pdf ... some remarks

Dear Herman,

I am back to work (had some important deadlines at the University of
Ulm) and will now again work on the implementation of my communication
patterns (providing the events). I only had a short look at your new
"ipc.pdf" proposal and because I am not yet sure that I got everything
right I send you this email on your private account.



Many of the concepts described in your paper are exactly what is inside
my communication patterns. Therefore, I assume that you are still
compatible with my communication patterns, right ?

I however got the impression (when browsing your proposal) that you are
concerned very much about various handlers and registering callback
methods. Is that the same what is described in my design document on the
various interfaces at the level of the framework user ? Or do you mainly
describe what then is inside the communication patterns ? What I do with
the communication patterns is to avoid that every consumer registers a
callback method at the producer side because then you have strong
dependencies between producer and consumer.  Where I got confused is
which thread executes which part of the various handlers (section 3.2).
If you look at my UML diagrams you can see that there is a clear
distinction between the user thread, the communication activity etc.
which allows you to provide various user interfaces like callbacks with
handlers or blocking calls etc. without ever blocking communication (by
the way that is the main issue with respect to avoiding deadlocks).

Another point is the "guard" (section 4.1.1). I use a guard at the
producer side of an event to decide whether the event should fire. The
guard itself belongs to the event but the parameters for its activation
check are send by the event activation. This allows one e.g. to get an
event if an activation specific set of parameters gets true. This is
very convenient for events !

Boris and I sent a draft on hierarchical state machines to the mailing
list some weeks ago. Have you looked at it ? What do you think ?


So what I would suggest is to explicitly make clear which parts are
design decisions at the "internal" part of the framework, which policies
are used within communication patterns etc. and which application
programmer policies and communication pattern interfaces result from
those underlying models (I think we are still compatible and you end up
with the proposed interfaces of the communication patterns). If you look
at my sources of the CORBA based implementation you can see how the
producer / consumer (or client / server) part of the patterns commuicate
by calling internal methods of their CORBA representations and how they
are decoupled using condition variables. That decoupling e.g. is very
important and can be found as policy in your proposal as well.


Looking forward to hear from you ....


Christian

--

---------------------------------------------------------------------
Christian Schlegel
FAW Ulm (Research Institute for Applied Knowledge Processing)
PO Box 2060
D-89010 Ulm
Germany

Tel. : ++49 (731) 501 8949
Fax  : ++49 (731) 501 999
email: [email protected]
WWW  : http://www.faw.uni-ulm.de/
---------------------------------------------------------------------