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

On Wed, 9 Oct 2013, S Roderick wrote:

> 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".
>
That's indeed it! Not more (so rather simple to understand conceptually)
but also not less (hence, capable of dealing with the "curse of API-ality"
problem that was the origin of this thread).

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

Sure...

> S

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