Re: CMSP 06. Data structures, not YAML
Jarkko Hietaniemi wrote: I really don't think we should have Perl data structures in files (that means Perl code, right?), because that indicates doing an eval, Not necessarily. Working in *a defined subset of* Perl syntax would mean that readers have both options. Evaling would probably be acceptable in situations where you're installing the module described by the META file, so this could be a convenient option in some small installations. Stats gatherers, who don't want to run code from the module, can use a safe parser as they do now. It so happens that I have a suitable subset of Perl syntax already defined. I needed to implement it a while ago for work purposes, and now it's on CPAN, as Data::Pond. It's similar in spirit to JSON, which of course gives the same kind of parsing choice for the JavaScript language. -zefram
Re: CMSP 06. Data structures, not YAML
On Fri, Oct 9, 2009 at 7:44 AM, David Golden xda...@gmail.com wrote: 06. Data structures, not YAML Proposal: The META spec should be defined in terms of (Perl) data structures, and not in terms of YAML. (Slaven Rezic) Comments: * This does not mean that I want to replace YAML by a Perl data dump (or maybe yes, but see below). It is just about the specification document: it should not talk about META.yml, but the META spec, and should not use the YAML data type names (mapping, sequence), but Perl data type names (hash, array). Agreed. * The actual serialization proposals could go into an appendix of the spec, or even in a new document. So whether it will be JSON, or YAML::Tiny, or YAML 1.1 could be decided later. I like the idea of different sections for data, serialization, and usage (the latter being how clients use it.) * In my opinion I would vote for *two* serialization formats: normal YAML as it is done currently (or even YAML 1.1), which would be used for statistical analysis (here we can force people to install the latest and greatest YAML parser), and a Perl data dump which is used by CPAN.pm etc. for configure_requires or similar stuff (here the user has probably a very bare perl installation, the minimum we can expect is the ability to parse Perl). Something similar is done with distroprefs handling in CPAN.pm: if .yml is available, fine, otherwise it's possible to fallback to .dd, a perl data dump file. I don't like having .dd as an option. We want to minimize evaluated code. * I am still fine that the examples in the spec are still expressed in YAML, because I think that YAML is a quite nice human-readable format. I'm be in favor of replacing all examples with Perl data structures, since they will map more clearly to how they will be generated and how they will exist after deserializing. We're talking about a spec for Perl programmers, so I think that's probably sufficiently human-readable. -- David
Re: CMSP 06. Data structures, not YAML
Ricardo Signes wrote: * David Golden xda...@gmail.com [2009-10-09T07:44:43] 06. Data structures, not YAML Proposal: The META spec should be defined in terms of (Perl) data structures, and not in terms of YAML. (Slaven Rezic) Agreed, but the spec should be very clear (perhaps, as said, in an appendix) how the data should be serialized and included in dists. I have no strong feelings about this except for what Ricardo wrote above: The serialization method needs to be prominently featured. Steffen
Re: CMSP 06. Data structures, not YAML
* Jarkko Hietaniemi j...@iki.fi [2009-10-09T10:11:35] I really don't think we should have Perl data structures in files (that means Perl code, right?), because that indicates doing an eval, and I don't want to eval any more random code off the 'net than necessary. Right. We definitely want a proper serialization layer. (JSON!) I think if read as a proposal to describe the data serialized in terms of Perl structures, rather than the serialization system's forms, this is great. (author is a string or arrayref not author is a character-vector or sequence) -- rjbs
Re: CMSP 06. Data structures, not YAML
On Oct 9, 2009, at 9:11 AM, Jarkko Hietaniemi wrote: I really don't think we should have Perl data structures in files (that means Perl code, right?), because that indicates doing an eval, and I don't want to eval any more random code off the 'net than necessary. I strongly agree that we should not be having perl code in the META file for security reasons. Although most people would use Safe to read it, there would be those that would not and could get caught out But the spec should also not be biased to a particular format, IMO. So describing what goes into the META data in terms of perl data types seems reasonable. The spec should contain a separate section which describes how the data is serialized Graham.
