Hallo and ... Re: [FR-devel] Latest YAML format

[why the lucky stiff]

Hello FreeRIDEiacs.  As consequence of my meeting Rich and Curt and
others at RubyConf, I'm coming onto the list with great interest in
FreeRIDE.  Not that I'm an IDE man at all.  But I see the value it will
add to the Ruby world.  I kinda think it's yummy.

So I'm just going to quickly introduce and then move onto YAML questions
from Laurent.

So, Hi.  I'm Why.  I've been a programmer since I was a young kid.  I do
mostly PHP development for work, but I recently did some Ruby and a year
from now I aim to do entirely Ruby development.  I write tons of
science-fiction (short stories; working on a series of books).  I aim to
do entirely writing ten years from now.

I also have a sort of weblog [http://whytheluckystiff.net/] where I can
talk freely about Ruby / YAML / other projects.

So I'm just going to jump into the YAML questions.  One thing to
remember about YAML is that YAML is not XML in any way.  The two do not
step for each other.  We aren't a stripped-down XML.  YAML decribes data
structures (Arrays, Hashes, Objects) directly.  XML is marked-up
content.

I'm not the creator of YAML, in fact I've only been involved since July.
So many of your questions may be posed better on the yaml-core list.
But I can say that in my experience of using YAML, it is a better fit
for most of my data storage use cases that XML.  A few basic reasons
why:

  - Cuts down the size of my documents by 15% or more.
    (Yesterday I cut raa-xml.xml down from 600k to raa.yml 490k. The
    RSS feed on my site why.xml is 64k, why.yml is 29k.)

  - I don't get nearly the problems with poorly formed YAML that I
    get with XML.

  - Round-tripping in YAML is a breeze.  Round-tripping in XML is a
    headache.  (Although REXML makes it easier, you're still walking
    a tree.)  This is a major advantage, especially if you plan on
    having a format that is both human-readable/-writable and 
    machine-readable/-writable alternately.

  - The API is simpler than available XML APIs.  (Perhaps with the
    exception of the XML Serialization package.)

These are big wins in my usage of YAML.  I can see good reason to want
these advantages in FreeRIDE.

Laurent Julliard (address@hidden) wrote:
> - It's yet another format to learn for our community of developers. I 
> assume that XML is already well-known by everybody. I'm not sure about 
> YAML.

We have a Cookbook available to instruct developers:

  http://yaml4r.sf.net/cookbook/

You can kind of look at it and get a picture of its difficulty.  I don't
think many people will care much about what format they need to use.  A
lot of developers will cut-and-paste the sample formats and edit them to
their liking.

The same thing could be said of Ruby-- yet another language to learn??

> - Are we sure YAML offers enough power to encode the properties file 
> that we will save when FR stops (like keeping the list of open files, 
> the list of breakpoints placed on each file,etc.) Again I don't know 
> YAML so I'm just asking here.

Absolutely.  If you are storing those properties in a Hash or even an
Object, then YAML will be perfect.  When you stop, you simply dump the
structure to a file like so:

  File.open( 'FreeRIDE.sav', 'w+ ) { |f|
    f.write( properties.to_yaml )
  }

YAML understands Ruby symbols, Integers, Floats, booleans, NilClass,
most anything you throw at it.

> - Is the Ruby community (or at least the YAML auhtor) committed to 
> maintain YAML4R as well as the XML parsers are?

My best answer to this would be to review the CVS repository at
SourceForge.  I check in once a week at least.  Although, the SF
repository is not my main repository.  Perforce on ttul.org gets
checkins everyday.

YAML.rb is easily one of the most active Ruby projects.

The yaml-core list has been slow this month, because we've all been out
spreading the word lately, but we've gone through thousands of messages
to develop the current YAML specification.

> - The fact of using YAML for the config file will not make XML 
> disappear from the scene. It is very likely that XML will surface in 
> other plugins (e.g using the jabber protocol to help in pair 
> programming or other similar cases).

Good point.  And I believe that YAML makes a better wrapper for XML than
XML does.  If you  are doing XML-in-XML, then you either have to encode
your XML document (ugly) or use a CDATA section (hackish).

With YAML, you can use a literal block:

  --- #YAML:1.0
  plugin: Jabber Protocol
  author: Kilmer
  sample_xml: |
    <message from='address@hidden' to='receiving-ID'>
      <body>Watson come here, I need you!</body>
    </message>

The literal block allows you contain text in which newlines are
preserved.  You can even embed YAML documents inside of each other
without needing to encode the document.
  
> - And last but not least, isn't this going to delay the availability 
> of the  first FR release....

True.  I was under the impression the plugin XML code still had a ways
to go, though.  I assure you there is no learning curve to applying
YAML.  Once you're document is loaded, then you're dealing with native
Ruby types.

Hope I've answered your questions okay.  I probably come off a bit
overly-confident, but I've lost that part of my brain that once
understood the use of XML in data storage.  So in an XML discussion, 
I tend to look at XML as a largely misplaced technology.

Anyways.  Glad to be a part of the list now and the discussions to
follow.

_why