[Rock-dev] YAML orogen config files

[Sylvain Joyeux]

> You didn't explain any reason to break with the syntax of yml.

It's both a matter of personal preference, and of cost vs. benefit of
the change.

Personal preference: I don't agree that it would be better to have one
more level of hierarchy in the YAML file. Sections are much easier to
find in the file (just search for the leading triple-dash) and given
that human-editing is still the main use-case, that's something I'd
rather optimize for. Moreover, there is more than name (there's also
chain and merge), integrating them would be even more awkward in pure
YAML (two levels of hierarchy ?).

Cost vs.benefit.
  Cost: it's there, it's deployed. Everyone need to change, and we'll
need to have backward-compatible files. "Splitting" such a file at
triple-leading-dash should not take you more than 30 minutes of
coding. If it does, use it as an exercise, and implement it in at
least 3 different programming languages.
  Benefit: from where I sit, doubtful.

Sylvain

On Fri, Dec 16, 2016 at 1:29 PM, Raul Dominguez <Raul.Dominguez at dfki.de> wrote:
> Hello Sylvain,
>
> sorry for the two months delay...
>
> On 20.10.2016 21:08, Sylvain Joyeux wrote:
>
> Could we change this? Why aren't the sections just the first level in the
> hierarchy of the config files?
>
> Because there was (actually, still is, but it's unused AFAIK) more
> metadata than just the name, and writing something that can separate
> the fields and parse the sections separately is not the end of the
> world. I personally don't see any major driver to change that.
>
> Even if there is more metadata, this can be included using the right syntax.
> You didn't explain any reason to break with the syntax of yml. What do you
> want to express that can not be expressed with the official syntax? The
> driver to change this, is that anyone can then use an exsiting yml parser to
> work with this files from any ruby script or library instead of having to
> implement any additional rock-config files parser.
>
> This is not a good practice, because we enforce the naming the files to get
> the tool working, right?
>
> Whether this is good practice or not is pretty much in the eye of the
> beholder. This is the convention-vs-configuration debate. I personally
> very much prefer - in this case - the "convention" solution because
> one *knows* where is the configuration for a given task. With the task
> model name in the file, you always end up with files whose file name
> do not match, and then both tools and humans *have* to read all files
> to figure out which files are applicable to a certain model.
>
> I accept that you have a fair point on this one but somehow I still don't
> like to have to parse the filename to get to know to which task it belongs
> too... Maybe I just have to get used to it.
>
> Kind regards,
> Raúl
>
>
> Sylvain
>
> On Thu, Oct 20, 2016 at 6:56 AM, Raul Dominguez <Raul.Dominguez at dfki.de>
> wrote:
>
> Hello Rockers,
>
>
> About the syntax:
>
> The Yaml files that are used for configuring the tasks have a syntax
> which is not proper Yaml.
>
> To separate the sections "--- section_name" is used. Officially '---' is
> the document header symbol.
>
> This becomes a problem when you try to use any available yaml parser
> either Ruby or C++.
>
> Could we change this? Why aren't the sections just the first level in
> the hierarchy of the config files?
>
>
> About the content:
>
> Currently the task to which the config belongs is not specified in the
> config file contents itself, any tool has to guess it by the name of the
> file. This is not a good practice, because we enforce the naming the
> files to get the tool working, right? Could we have a field "Task" which
> informs about to which task the config is associated.
>
>
> Thanks for your feedback!
>
>
>
> Kind regards,
>
> Raúl
>
>
>
>
> --
>   Raúl Domínguez (M.Sc.)
>   Space Robotics
>
>   Besuchsadresse der Nebengeschäftsstelle:
>   DFKI GmbH
>   Robotics Innovation Center
>   Robert-Hooke-Straße 5
>   28359 Bremen, Germany
>
>   Postadresse der Hauptgeschäftsstelle Standort Bremen:
>   DFKI GmbH
>   Robotics Innovation Center
>   Robert-Hooke-Straße 1
>   28359 Bremen, Germany
>
>   Tel.:     +49 421 178 45-6617
>   Zentrale: +49 421 178 45-0
>   Fax:      +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
>   E-Mail:   raul.dominguez 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
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
>
>
> --
>  Raúl Domínguez (M.Sc.)
>  Space Robotics
>
>  Besuchsadresse der Nebengeschäftsstelle:
>  DFKI GmbH
>  Robotics Innovation Center
>  Robert-Hooke-Straße 5
>  28359 Bremen, Germany
>
>  Postadresse der Hauptgeschäftsstelle Standort Bremen:
>  DFKI GmbH
>  Robotics Innovation Center
>  Robert-Hooke-Straße 1
>  28359 Bremen, Germany
>
>  Tel.:     +49 421 178 45-6617
>  Zentrale: +49 421 178 45-0
>  Fax:      +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
>  E-Mail:   raul.dominguez 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