From: Brian I. <in...@tt...> - 2002-04-06 01:31:21
|
Some real world feedback. ----- Forwarded message from Richard Soderberg <ric...@da...> ----- From: Richard Soderberg <ric...@da...> Date: Thu, 4 Apr 2002 11:17:50 -0500 To: in...@cp... Subject: Fwd: Config with properties X-Mailer: Apple Mail (2.481) This caught my attention. Have you seen this message already? It's dated a month back. R. Begin forwarded message: > From: JVr...@sq... (Johan Vromans) > Date: Mon Mar 04, 2002 04:36:31 PM US/Eastern > To: "Ken Williams" <ke...@ma...> > Cc: mod...@pe... > Subject: Re: Config with properties > > [Quoting Ken Williams, on March 4 2002, 15:17, in "Re: Config with > prop"] >> 1) Why is this better than using Data::Dumper for saving config info? >> Is it so that you can hand-edit the config files? > > Yes, manual maintenance of the config files is a design goal. > >> Do you know about YAML, on CPAN? > > Yes, but I rejected it due to its alpha status, unneeded complexity > and because it relies on whitespace indentation to represent > structure. Imagine what happens if people start editing the files and > use tabs with different presets?. > > (I also rejected most other Config::* and XML::* modules for varying > reasons.) > >> 2) Is it appropriate to use the Config namespace, since the Config.pm >> module is a pretty different beast? > > Config::Properties is an existing CPAN module, with similar > functionality. My module does the same, with extensions. > However, AppConfig::Properties would be a suitable name as well. > > Thanks for your feedback. > > -- Johan > ----- End forwarded message ----- |
From: Clark C . E. <cc...@cl...> - 2002-04-06 02:58:32
|
On Fri, Apr 05, 2002 at 05:31:16PM -0800, Brian Ingerson wrote: | Some real world feedback. | | >> Do you know about YAML, on CPAN? | > | > Yes, but I rejected it due to its alpha status | | > unneeded complexity Perhaps for simple configuration and/or log files we are too complex. However, people are using XML for log and configuration files; and XML is more complex than YAML. | > and because it relies on whitespace indentation to represent | > structure. Imagine what happens if people start editing the files and | > use tabs with different presets?. 1. I think our tab policy now is pretty good, as the above problem with people using tabs with different presets is explicitly covered. We need to cover this in the FAQ and modify the spec so that it is clearly articulated way-up-front. 2. There are people who like tabs, for example: http://www.scottsweeney.com/projects/slip I think indented vs tagged is just a religious item like vi vs emacs. Of course, there is only one right answer... *smile* 3. We could (should?) devise another non-tab based syntax that has the same information model. In this way all of our tools can work regardless of which religion they want. We could even allow for multi-line [] thingys...*sigh* Hmm. I guess the deciding fact will be lots of good implementations. Many people I know think XML is ugly till they started to use it day in and day out. Best, Clark |
From: Neil W. <neilw@ActiveState.com> - 2002-04-06 03:56:51
|
Clark C . Evans [05/04/02 22:02 -0500]: > Perhaps for simple configuration and/or log files > we are too complex. However, people are using XML > for log and configuration files; and XML is more > complex than YAML. [Warning: rant] I use YAML a lot at work, and the only (real) complaint I have is that the YAML spec didn't make it a requirement for the #YAML:xxx tag to change with each release of the spec, before we settle down to an approved 1.0 status. I still have a bunch of old files lying around that look like this: --- #YAML:1.0 % foo: bar baz: com This claims that it's a 1.0 document, because the spec was called 1.0 last year in September, as it is today. But September-01's YAML is different from April-02's YAML. How different? Different enough. IMHO, YAML parsers of today should croak on #YAML:1.0, and we shouldn't be encouraging people to use that. We should be encouraging people to use whatever spec numbering system we're using: --- #YAML:10mar2002 foo: bar baz: com When we declare the spec frozen (really frozen) we should endorse a version number. > Many people I know think XML is ugly till they started to use it day > in and day out. Let's be fair: XML is pretty as long as you _make_ it so. Machine-generated XML tends to look awful. YAML looks nice because it has to: <?xml version="1.0"?> <package name="YAML" version="0.30" publisher="CPAN"> <author name="INGY" /> <tarball location="authors/id/I/IN/INGY/YAML-0.30.tar.gz" /> <modules> <module name="YAML" version="0.30" /> </modules> <scripts> <script name="ysh" version="" /> </scripts> <license type="Perl" from="YAML.pod"> This module is free software. You may use, redistribute, and/or modify this module under the same terms as Perl itself. </license> </package> --- #YAML:1.0 !activestate.com/PPM/package_description name: YAML version: '0.30' publisher: CPAN author: INGY tarball: location: authors/id/I/IN/INGY/YAML-0.30.tar.gz modules: - name: YAML version: '0.30' scripts: - name: ysh version: "" license: type: Perl from: YAML.pod content: ] This module is free software. You may use, redistribute, and/or modify this module under the same terms as Perl itself. Both of those look reasonable to me. Of course, what comes out of XML-producing systems often looks like this: <?xml version="1.0"?><package name="YAML" version="0.30" publisher="CPAN"><author name="INGY"/><tarball location="authors/id/I/IN/INGY/YAML-0.30.tar.gz"/><modules><module name="YAML" version="0.30"/></modules><scripts><script name="ysh" version=""/></scripts><license type="Perl" from="YAML.pod">This module is free software. You may use, redistribute, and/or modify this module under the same terms as Perl itself.</license></package> Whereas YAML-producing systems look just as nice as the human-typed version. Leading me to my belief that XML is really a binary protocol. If you can't read it, it isn't text. (I can't wait for YAML-RPC to take off. A colleague of mine showed me an example of it working, but there are only two clients in the world :) Later, Neil |
From: Clark C . E. <cc...@cl...> - 2002-04-06 16:28:13
|
On Fri, Apr 05, 2002 at 07:56:38PM -0800, Neil Watkiss wrote: | I use YAML a lot at work, and the only (real) complaint I have is that the | YAML spec didn't make it a requirement for the #YAML:xxx tag to change with | each release of the spec, before we settle down to an approved 1.0 status. Yes, this has been a problem. My apologies. I think we are very close to a final version, do we want to call it 1.1? | When we declare the spec frozen (really frozen) we should endorse | a version number. | Let's be fair: XML is pretty as long as you _make_ it so. Unfortunately, pretty printing is not simple in XML. These two documents below have a very different DOM representation <root><hello>world!</hello></root> and <root> <hello>world!</hello> </root> The latter has introduced two additional text nodes and thus root has 3 children instead of one. This is why the "machine produced" XML always looks awful. If it pretty-printed the XML, it would be changing the DOM structure of the document. | Leading me to my belief that XML is really a binary protocol. If you can't | read it, it isn't text. (I can't wait for YAML-RPC to take off. A colleague | of mine showed me an example of it working, but there are only two clients in | the world :) ;) Clark |
From: Neil W. <neilw@ActiveState.com> - 2002-04-06 18:35:51
|
Clark C . Evans [06/04/02 11:31 -0500]: > Unfortunately, pretty printing is not simple in XML. These > two documents below have a very different DOM representation > <root><hello>world!</hello></root> > and > <root> > <hello>world!</hello> > </root> > The latter has introduced two additional text nodes > and thus root has 3 children instead of one. This is why > the "machine produced" XML always looks awful. If it > pretty-printed the XML, it would be changing the DOM > structure of the document. Crap like that is why I don't use DOM or SAX to access XML documents. XML::Simple parses both of those streams like this: $VAR1 = { 'root' => { 'hello' => 'world' } }; Later, Neil |
From: Brian I. <in...@tt...> - 2002-04-06 20:31:22
|
On 05/04/02 22:02 -0500, Clark C . Evans wrote: > On Fri, Apr 05, 2002 at 05:31:16PM -0800, Brian Ingerson wrote: > | Some real world feedback. > | > | >> Do you know about YAML, on CPAN? > | > > | > Yes, but I rejected it due to its alpha status > | > | > unneeded complexity > > Perhaps for simple configuration and/or log files > we are too complex. However, people are using XML > for log and configuration files; and XML is more > complex than YAML. > > | > and because it relies on whitespace indentation to represent > | > structure. Imagine what happens if people start editing the files and > | > use tabs with different presets?. > > 1. I think our tab policy now is pretty good, as the above problem > with people using tabs with different presets is explicitly > covered. We need to cover this in the FAQ and modify the spec > so that it is clearly articulated way-up-front. +1 +1 > > 2. There are people who like tabs, for example: > http://www.scottsweeney.com/projects/slip > I think indented vs tagged is just a religious item > like vi vs emacs. Of course, there is only one > right answer... *smile* :) +1 > > 3. We could (should?) devise another non-tab based syntax > that has the same information model. In this way all of > our tools can work regardless of which religion they want. > We could even allow for multi-line [] thingys...*sigh* -1 I think we're elegantly covered. No changes needed. Just good error meassages and documentation. > > Hmm. I guess the deciding fact will be lots of good > implementations. Many people I know think XML is ugly > till they started to use it day in and day out. +1 Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2002-04-06 17:05:07
|
On Fri, Apr 05, 2002 at 05:31:16PM -0800, Brian Ingerson wrote: | Some real world feedback. I've added a FAQ item to our website. 1. What happens to YAML when people edit the files and use tabs with different presets? By default, a YAML parser rejects streams using tabs for indentation. For those which must use tabs, an explicit declaration, #TAB:N, is provided which can be used to inform the YAML parser of tab policy. If tabs are used, we cannot solve the case where a YAML file created and marked with #TAB:8 (vi) is edited with an editor using #TAB:4 (visual studio), however, we think that the road sign should provide adiquate warning. Further, the default form for YAML printers is to always use spaces for greatest interoperability. |