Re: [Bug 1044] New: Broken error propogation logic within solvers
S Roderick <[email protected]>
| Newsgroups | gmane.science.robotics.orocos.devel |
|---|---|
| Message-ID | <[email protected]> |
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. S -- Orocos-Dev mailing list [email protected] http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev