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

On Oct 9, 2013, at 02:32 , 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).
> 
> If you ever use this design pattern, please give credits to Markus!!!!

This sounds like a good idea Herman, but can you provide a concrete example of this potential new approach. Some of what you're talking about sounds like VTK's data pipeline approach, though perhaps with more active "scheduling" and "control".

In all reality, we're not interested in some future potential approach. We need a fix, now, for the problems with the current API. When this future approach is available we'd love to review it, but until then ...
S
-- 
Orocos-Dev mailing list
[email protected]
http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev