Re: [Bug 1044] New: Broken error propogation logic within solvers

On Tue, 8 Oct 2013, Sagar Behere wrote:

[...]
> >> Thanks for the nice summary of problems described below! They are exactly
> >> the reason why I started to fight severely against class libraries for
> >> "solvers" of any kind, and the "information hiding behind standardized
> >> APIs" that goes naturally with it. Both are not scalable, and too
> >> restrictive.
> >>
> >> Instead, we are now developing a "function blocks on steroids" framework,
> >> based on Markus Klotzbuecher's ideas and code. These "micro blocks" are
> >> positioned somewhere between OO class libraries and RTT components,
> >> introducing "scheduling" and "composable Ports" as the major primitives to
> >> deal with the mentioned problems.
> >
> >
> > Could you elaborate a bit on how this framework would deal with the specific problem Stephen
> describes?
> 
> +1
> 
> I am interested in this too.

A software application consists of the integration of many, many functional
pieces of code, each with its own "monitoring" information. The
traditional API-based approach has problems with letting _all_ the
monitoring information be accessible in the whole application, _because_
one wants to communicate all that information through the method call
signature. This does not scale, as is proven by many, many use cases, KDL
being one of them. The "functional components approach", on the other hand,
allows an _application_ to create "ports" and connect them to _any_ piece of
information that is relevant for the _application_. (While the API-based
approach let the _API designer_ decide about what to have visible through
the API and what not.) In order to allow the design of such flexible
application architectures, it is very wise to foresee a "scheduler"
activity that calls the right functionalities in the right way and under
the right conditions. (This includes calling the right _port communication_
functionalities, as well as the right "information forgetting/storage"
functionalities.)

_All_ the successful systems I have ever seen, including the human, allow
even the highest levels of abstraction in the system (e.g., the CEO in a
company) know about low-level errors immediately and fully, when it is
relevant (in the CEO's case: when there is a leak in a pump in the
Fukushima reactor enclosure, the CEO should be able to have direct access
to this information (just by 'switching' the right communication "port",
without that information having to be passed through layers and layers of
"lower level" APIs).

If you ever use this design pattern, please give credits to Markus!!!!

> /Sagar

Herman
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev