Taking it from the top, just so its all clear.
What we're looking for in a data format... 1. Human readable/writable. That means a programmer can look at it with cat or Notepad and immediately understand the contents. 2. Cross-platform. The main concerns are Perl, Python and Ruby. 3. Safe. ie. Nothing to eval, no possible nasty security issues. 4. Simple to emit. So MakeMaker and Module::Build can turn a Perl hash into data without requiring an extra module. 5. Sensible data model. Something which maps well into the hash/list/scalar data which Perl, Python and Ruby uses. Why we're not using... Data::Dumper is not a cross-platform data format, it is not safe to eval even using Safe and it is not the easiest thing for humans to read/write. So that's #1, 2, 3 and 5. Storable is not a cross-platform data format and it is not a stable format nor is it human readable/writable. XML models data as trees which isn't easy to map into Perl. It is also not very pleasing on the eye in raw form. That's all the serious contenders I know about. On to the specifics you've asked about... On Sat, Mar 08, 2003 at 06:41:17PM +0100, Jochen Wiedmann wrote: > thanks for the pointer Ken. I have carefully read the thread > and found nothing that convinced me. In fact I have missed some > arguments: > > - data files generated by Data::Dumper can be evaluated in a > "Safe" compartment. Safe is not entirely safe. And, as mentioned, Data::Dumper is Perl-only. We'd like our meta-data to be readable in other languages. > - An XML Writer would be required by the module author only. > An XML Reader is already part present on most systems, with > a definitely growing number. A YAML writer is only required by the module author only if at all. MakeMaker does not depend on YAML.pm, Module::Build merely recommends it. A YAML reader is not required by the module user or to install the module. > - I recently started to have a look at Module::Build and I > wholehearty support it: In particular, because it will finally > simplify module installation on Windows and commercial Unix > systems, where one typically doesn't have a C development > environment. But my guess its most important problem for > acceptance will be its dependence on "esoteric" modules like > YAML or ExtUtils::ParseXS. (Esoteric == not part of the > ActiveState repository, aka "target group") *I* (module > author) had no problem installing these prerequisites, > but I wouldn't like to receive 10 emails a week asking > "How do I install these modules?" YAML and ExtUtils::ParseXS are both *optional* dependencies of Module::Build. They need not be installed for it to work. This is expressed in both the Build.PL and META.yml files. Everything required is in the Perl core. Furthermore, if (ActiveState|RedHat|Debian|Sun|...) isn't keeping their package repository up to date with what's on CPAN, that's not our problem. They package things based on what's used, but we don't use things based on what's packaged. Its nice if there's packages for the modules we need, but I'm not going to wait. They'll catch up. But yes, MM and Module::Build will keep their dependencies to a bare minimum, ideally to only what is available in Perl 5.6 or 5.5. But recommended (ie. optional) dependencies are fair game. > - You think XML isn't human readable? What do you expect > the typical joe user to do, if she or he finds an unknown > file? Double-clicking it! In the case of XML that means, > that a properly configured browser opens the file, formats > it nicely, highlights tags, offers to hide or view sections. This is a less than ideal scenario. Ideally you don't want a special pretty printer at all. cat or Notepad should sufficient. > - You happy guys seem to live in a Perl-only world. My Envy! > I don't and most other peoples also do. However, in a > heterogenous world, a portable data format is worth much > more than a data format that requires me to write a parser. YAML is a portable data format. Parsers exist in Perl, Ruby and Python with a C library coming along and a Java implementation in the works. The spec is freely available here http://www.yaml.org/spec/. YAML was designed with Perl, Ruby and Python specificly in mind. The Ruby library is probably the best of the bunch. We expect Perl's use of YAML to further drive development of better and more YAML parsers. Having a portable data format is very important to us, we have plans to extend the Module::Build concepts beyond Perl. There are already plans to write a Module::Build-like library for Ruby. This is why Data::Dumper and Storable are not acceptable. We are most definately *not* living in a Perl-only world.
