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

On Mi, Okt 09, 2013 at 08:43:37 +0200, Ruben Smits wrote:
> Hi Herman,
> 
> On Wed, Oct 9, 2013 at 8:32 AM, Herman Bruyninckx
> <[email protected]> wrote:
> 
>   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).
> 
> (I hope you realize that this is a bad example. Sadly, in most companies your
> example is far from the truth.)
> I think this is exactly what we have in mind. Instead of propagating the errors
> upstream through the API calls (being CartToJnt or similar), we would like to
> add an error "port" to the solvers. So if a top level solver would report "an"
> error, the application can contact all low-level solvers error "ports" to see at
> which level the error occurred and what happened at each respective level
> instead of having to serialize and deserialize error codes through the API
> calls.
> 
>   If you ever use this design pattern, please give credits to Markus!!!!
> 
> It's hard to give credit if you have nothing to refer to ;)

I quite certain I don't deserve credit for this... Function blocks
have been around for decades and I'm certain there are many engineers
out there applying this pattern without even noticing it as such.

But it _is_ the Right Thing (TM) to do!

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