[Rock-dev] YAML orogen config files

[Raul Dominguez]

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

It not much more costly for a human to search for "---" than for 
"section" (might be even more intuitive). In my opinion, it's more 
awkward to use non standard YAML files that are not readable yaml 
parsers. One of the appealing things of using yaml is automatic parsing.

> Cost vs.benefit.
>    Cost: it's there, it's deployed. Everyone need to change, and we'll
> need to have backward-compatible files.
I agree with you, keeping backward-compatibility will be costly, 
especially without a good plan.

> "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.
No. Pre-process scripts for non-standard YAML files is not an 
interesting exercise and I don't think this is a didactic programming 
exercise: Feels more like patching to deal with wrong stuff. My point 
is: I find it not elegant to force people to integrate these kind of 
scripting in their work.


Kind regards,
Raúl


On 16.12.2016 17:17, Sylvain Joyeux wrote:
>> 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

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