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

On Wed, 9 Oct 2013, S Roderick wrote:

>
> On Oct 9, 2013, at 07:05 , Herman Bruyninckx <[email protected]> wrote:
>
>> On Wed, 9 Oct 2013, S Roderick wrote:
>>
>> (Could the experienced and IT-savvy developers on this list please refrain
>> from using HTML posts... It makes proper/unambiguous/client-independent
>> indentation of replies impossible.)
>>
>>> On Oct 9, 2013, at 02:43 , Ruben Smits <[email protected]> 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.
>>> Our idea is very slightly different from this. All solvers should inherit from a Solver
>>> Interface class that provides simply the latest error number. If a lower level solver fails then
>>> it stores the error and its parent solver returns an error code indicating which lower level
>>> solver failed. Now the caller, having called the parent solver _but_ having access to both
>>> parent and the lower level solver (the application, at least in our use cases, has to have
>>> created both explicitly) realises that the parent failed due to a faliure in a particular lower
>>> level solver, and now the application can query that particular lower level solver to determine
>>> what happened.
>>
>> Way too complex! And too much coupling: "components" have to have too much
>> information about each other; in our pattern, only _one single_
>> "component", the application, has to know about the exact interaction
>> capabilities of all other components. In addition, the "error number" is
>> only the last possible resort for proper functioning of a complex system:
>> much more important are the "continuous progress QoS" monitoring data that
>> interacting components should exchange with each other. And adding these to
>> your design suggestion makes the coupling ever more complex.
>> In addition bis, relying on a "query interaction" policy to find out what
>> went wrong is running behind the facts, which should be _avoided_ in the
>> first place. (This ambition was, by the way, _the_ main reasong for use to
>> include QoS monitoring "ports" in all our designs.)
>
> Sounds great, but do you have a working implementation? We do, and are
> happy to provide it to the community. I think that you're focused on long
> term improvements, which is great. But as I wrote, we need a fix now and
> are happy to patch the current approach to keep things going until your
> solution is in place.

That's a deal I would take at any moment! :-) The ETA for our solution
depends on how fast Markus and Azamat can work... :-)

> S

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