[Rock-dev] Proposal: Rock Apps

[Sylvain Joyeux]

On 10/13/2011 01:47 PM, Alexander Duda wrote:
>> 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.
In any case: one can always have a "system-wide app" in e.g. 
install/share/rock where the packages install their stuff. This way, the 
tooling needs only one way to find things (ROCK_APP_PATH and the app 
structure) and (if the consensus goes this way) packages can install 
package-specific files.
>> 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.
(btw: it is "migration" not "immigration". "immigration" refers to 
people coming to live in a foreign country)

Some log migrations *are* application-specific. Example: iMoby that 
misconfigured the GPS module for a while. That's not package specific, 
that's project-specific. In general, I would be OK if the consensus goes 
towards your approach, but I would have the same structure in 
install/share/rock/ than in a "normal" app (again, to reduce the 
confusion and the work done in the general loading code).

The problem with having migration scripts in install/ is that we are 
going to have an app for rock models (because, frankly, I really don't 
want to have them split up from my experience) and *then* have migration 
scripts elsewhere.

So ... That's two folders by default:

   install/share/rock
   apps/rock

Confused, anyone ?

>>> 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 ;-)?
You always run a script *from* within a given app (the same way than is 
done from the supervision). The logs go into the logs/ folder of that app.
> Moreover most our system have a separate partition for log files
> therefore I would really like to globally set it.
I don't like it because you are going to mix logs without giving any 
context. If I choose to have a "asguard" app and a "separated pan-tilt 
unit" app, I don't want their logs to mix (I chose to separate them for 
a reason).

In principle, one could anyway configure on a per-app basis (again, just 
how it is done in the supervision). You could then choose to have all 
YOUR apps to put their logs in a global folder. I would personally 
prefer having, by default, logs in a app-local logs/ folder (because, 
from experience, it's something that works fine). Moreover, what if the 
user does not define any global folder ?
> There are just too
> many people which does not care and polluting the main partition.
I don't understand what you mean by that. 3 apps, 3 logs folders tops. 
Hardly polluting.

-- 
Sylvain Joyeux
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
-----------------------------------------------------------------------