From: John Goodwin <jegoodwin3@ea...> - 2002-01-28 22:01:49
Of course when I get a new hammer everything is a nail. So I've
stumbled across various real-world uses for YAML. These may not be
wildly exciting, but they might help us think of "use cases" we haven't
thought of before.
My company specializes in QA, so some obvious areas are: serializing
test data, test results, and log files. The main advantage of this sort
of serialization is that your programs can write out "objects" rather
than text, and the output can be re-instantiated in memory by loading
the output. This is great for capture/replay applications, structured
test cases, etc. I experimented with just pushing objects onto an output
stream list and serializing the object later for output. This has one
big advantage--you can write raw YAML or "interpret" the objects for
custom output without touching your core program.
Another thing I realized is that YAML could be used a bit like the
"expect" program. In case you are not familiar with "expect", it is a
TCL based package that handles the input and output requirements of
command line Unix programs so you can do send/expect automation. Send a
string, wait for a regex, trigger an action. Perl has an expect module
but it is not a full-featured as TCL's.
A lot of the utility of Expect is that it gives you ways of controlling
multiple "channels" to the same program, in a way that mimics what
humans do by examining output. YAML streams are objects, so they
inherently support multiple channels. That is, if stdin is reading YAML,
you can have a control channel and an input channel, and sort them out
in memory after acquiring the two-channel input object. Or you can keep
stderr and stdout separate YAML objects on a single stream, and
interpret them to "look like" traditional output, without confusing the
two streams in the storage format. Very often I need to analyze output
without errors or errors without output. That is hard with a simple
shell redirect unless I was thinking ahead at the time. :)
So maybe Perl doesn't need a better Expect. You can use YAML as an
adapter--your control program reads YAML and interprets it by managing
multiple processes, pipes, etc. This is more straightforward than
Expect, which tries to overload stdin/stdout/stderror with complicated
and non-intuitive control semantics.
A final thought. A very common problem is object-to-object conversion.
The traditional way to do this is convert object system A into an
Abstract Syntax Tree, then convert the AST to object system B. If YAML
serializes AST, we have a semantically neutral and syntactically
consistent way of storing instance data and metadata.
Just some ideas...