[Rock-dev] Proposal: Rock Apps

[Alexander Duda]

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

Ok, I see your point. 
I was thinking of an app in a different way than you do. You have
obviously roby/supervision in mind in contrast to that I was thinking
more of normal run scripts and GUIs.

Have you had a look on https://kepler-project.org/? I have the feeling
your propose is going into the same direction. You want to share work
flows. If this is the case the word rock-app is maybe misleading.

> > 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.
Still-. If I am modifying a base type I think the conversion belongs to
the package where I did the modification otherwise it is most likely to
get out of sync. The conversion for types which are using the modified
type are automatically converted by the converter if it knows the
conversion for the embedded base type.

> 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.
--> That's wrong with /install/share/rock/log/migration?
and storing the immigration scripts in the orogen package 
declaring the type.

> > 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.
If you have more than one app which folder is going to be used ;-)?
Moreover most our system have a separate partition for log files
therefore I would really like to globally set it. There are just too
many people which does not care and polluting the main partition.

Alex


-- 
Dipl.-Ing. Alexander Duda 
Unterwasserrobotik

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

Phone: +49 (0)421 178-456620
Fax:   +49 (0)421 178-454150
E-Mail: alexander.duda 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