On Mon, Sep 30, 2019 at 05:21:51PM +0200, Peter Krempa wrote:
On Mon, Sep 30, 2019 at 15:48:29 +0100, Daniel Berrange wrote:
On Mon, Sep 30, 2019 at 10:47:39AM +0200, Martin Kletzander wrote:
> On Fri, Sep 27, 2019 at 01:52:19PM +0100, Daniel P. Berrangé wrote:
> > This is a followup to a previous PoC patch I submitted a
> > month ago:

[...]


The choice of YAML is a valid point to use as that is definitely adding
a new language where one already exists (XML) that is expressive enough
to cope with the problem. As you saw the original v1 did indeed use XML
for this reason.

The decision to try YAML was an experiment to see if the simplicity and
readability of YAML would outweigh the cost of having another data language.
Personally I think it is a net win to use YAML instead of XML, but it
would not be the end of the world to go back to the v1 approach using
XML if people really want a less readable language just to not have to
add another data language.

In my opinion this is a misunderstanding.

Whether it's YAML or XML used for syntax is not that important. What is
important is that the new 'language' is the custom declarative language
which uses YAML or XML to express the constructions.

It's custom and barely documented. To get to the documentation you need
to read the source of the interpreter where you need to transform it
mentally to what it translates to.

Yes, that is the more concerning one, thanks for formulating my thoughts better.
I really like YAML and I would definitely go for that if choosing a format for
similar purpose as yours.

It's like ansible.  YAML is a good fit there (debatably), but even if you know
python, YAML and jinja templating, you still need to learn ansible to actually
be able to write any YAML for it.

Attachment: signature.asc
Description: PGP signature

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to