Re: Minutes of mini-meeting at KTH, Feb 28 - March 1st 2002

Herman Bruyninckx wrote:

Hi,

Since I have been out it took me some time to respond. Of course, I accept
that the configuration pattern is not taken into consideration at the moment.
However, the configuration pattern is NOT the "ultimate escape" pattern and it
is described in greater detail in my newest release of the communication
patterns. I put this document onto my web page tomorrow  (I will announce this
separately). Once again, the communication pattern is used to cancel blocking
method calls of communication patterns in an ordered way. This is needed to
cope with and prevent a component from transient states. These states can
occur when one component is already deactivated while another component to be
deactivated still waits for responses. Activation / deactivation is needed to
allow a sequencing layer or whatever to control configurations and therefore
control the settings of concurrent activities based on bounded resources.

Christian

> Minutes of the mini Orocos meeting at KTH, Stockholm
> February 28th -- March 1st, 2002
>
> Attendees:
> Henrik Christensen, Anders Oreback, Peter Soetens, Herman Bruyninckx
>
> Agenda:
> 1. Communication Patterns
> 2. Orocos Object Hierarchy (OOH)
> 3. Anders Oreback will work in Leuven for two weeks
> 4. PhD Lars Petersson
>
> 1. Communication Patterns
> =========================
> - The basic software patterns presented previously by Christian Schlegel
>   are a good basis to start from. Anders will produce a short document that
>   summarizes these patterns.
>
> - The suggestion is not to take the Configuration Pattern into
>   consideration at this moment, because it's like the many ``ultimate
>   escape'' patterns that tend to make software systems prone to bad use:
>   it's the kind of thing that people will start to use as soon as they
>   don't find what they need in the available API.
>   Therefore, if such a non-covered need arises, it will be better to
>   design and implement a new specific communication pattern, instead of
>   delegating the solution of the missing feature to the Configuration
>   Pattern.
>
> - The suggestion is to use the IDL (Interface Definition Language) of
>   CORBA as the language with which to _specify_ the API of the
>   communication service, irrespective of what programming language
>   will be used in the implementation. The motivation is that it's
>   difficult to motivate why to use something else.
>
> - All people should investigate whether their communication needs are
>   covered by the presented Patterns. If not, please report that fact
>   on the mailinglist. If the Patterns do suffice, start using
>   them, and using them exclusively, in all Orocos work.
>
> - The communication patterns are inherently independent of the types and
>   the content of the information that they communicate. Hence, there
>   should ideally be no dependence on the rest of the Orocos project, and
>   the implementation could be an independent package. In addition,
>   we might find already existing implementations of the communication
>   patterns (such as in GNOME or KDE). The Orocos implementation should
>   preferably be light-weight; (i) Orocos probably doesn't need
>   much feature bloat, and (ii) it would be extremely nice if we could use
>   the same code in different levels of the software (e.g., in real-time,
>   as well as in widely distributed systems).
>
> - The communication patterns will/should work with any object, and
>   explicit object serialization should be kept out of the API.
>

--

---------------------------------------------------------------------
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/
---------------------------------------------------------------------