[Rock-dev] Proposal: Rock Apps

[Sylvain Joyeux]

On 10/12/2011 08:00 PM, Alexander Duda wrote:
> First of all why do we need dependencies between the "Apps"?
> ->   Most of the stuff insight the package is going to be ruby therefore
> I have the feeling this will end up in a real mess if one app depends on
> multiple other apps (How can a developer ensure that he is not breaking
> dependent Apps?)
The idea behind dependencies is to share "common" stuff like models and 
log convertion/sanity scripts. The main target being to have a "core 
rock" app that defines common models, data services and log 
convertion/sanity checks.

You will obviously have the exact same issues than with anything that 
has dependencies. Component developers must not break interfaces, 
library developers must not break APIs, app developers will need to make 
sure that changes to what they "export" (models, log convertion and 
sanity checks) stay backward compatible.

> ->   The calibration example is for me something which definitely should
> go to the orogen module of the sensor or the thing which shall be
> calibrated and not in its own app.
Except that calibration is usually a multi-device thing, or a 
device-generic one (e.g.: any camera), and require more information 
about the system (e.g.: configuration files, transformer configuration, ...)

What I personally want to push with apps is a "functional view" of Rock, 
which is IMO orthogonal from the "component view" we have. In ROS, this 
is done with stacks. However, stacks don't do the trick for me as they 
apply on both the "software package" and "system functional" aspects.

> ->   If each app is self contained we do not have to announce it to the
> software stack. Autoproj knows about them anyway if someone wants to
> list them. Or we could even install them to install/apps
Apps do not have to be installed. In my mind, we *will* have 
dependencies between apps (read further for more). Now, whether they 
should be explicit or implicit, I don't know.

> Second:
> Why is there a need for migration scripts in an App folder?
> ->  this should go to the type definition (orogen task) or everyone else
> using the type/ task is not getting the migration script.
I don't agree. Type migration is a very "system-wide" concern. When you 
add a migration for base/Time, you actually affect *every type* that is 
using base/Time somehow.

My idea behind the proposal was to have only a few places where these 
"system-wide" files were placed (when thinking about it, I thought that 
a typical developer would have 2-3 apps installed on his system). The 
underlying idea was to have a "Rock app" where all rock-wide type 
convertion scripts would be added for Rock types.

This way of thinking is built upon my personal experience with Roby 
models. I started placing them in the component that defined them, but 
that ended up being totally unmanageable, as -- by definition -- Roby 
models have roots in system definition (data services, device models, 
generic compositions).

As we all noticed, scripts in component's scripts/ folder tend to 
require much more than "just the component" from the package. It ends up 
having people add unneeded dependencies between packages just so that 
their scripts work :(.

Moreover, as one of the main integration guy for iMoby, it is really 
painful to not have a place where I have an overview of what I run to 
double-check results, replay log files, ...

Finally, and more importantly, one (personal) goal for these apps is 
that people transition slowly to using the supervision even for their 
day-to-day scripts. That's possible only if done in a structure where it 
is manageable.

> Third:
> Why is there a need for a log folder?
> ->  the app folder is usual under a version control so why polluting its
> folder structure with log files which are not going to be committed?
This is not only "version control" structure but also runtime structure. 
The log/ directory is populated at runtime (and does not have to exist 
in the VCS)

> ->  Maybe we could add a default log path to the environment
I'd like to *not* add even more environment variables to the 
environment. When running a system (these days, using Roby), I 
personally very much like that I can know *for sure* where the log files 
are.

> Fourth:
> Why is a sanity check not a script?
> -> I would place it in scripts/sanity
Because sanity checks would follow the same "pattern" than log 
convertions. They are configuration files for a generic rock-log-sanity 
checker.
-- 
Sylvain Joyeux (Dr.Ing.)
Space & Security Robotics

!!! Achtung, neue Telefonnummer!!!

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Phone: +49 (0)421 178-454136
Fax:   +49 (0)421 218-454150
E-Mail: robotik at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.:    DE 148646973
Steuernummer:  19/673/0060/3
-----------------------------------------------------------------------