Re: proplib and the jet age

[Marc Balmer <marc%msys.ch@localhost>]

Am 05.01.2013 um 10:07 schrieb Jochen Kunz <jkunz%unixag-kl.fh-kl.de@localhost>:

> On Sat, 5 Jan 2013 00:25:19 +0000
> David Holland <dholland-tech%netbsd.org@localhost> wrote:
> 
>> If you're talking about using Lua syntax as the transfer format, I
>> don't see any advantage over e.g. JSON and the disadvantage of being
>> much less widely used elsewhere.
>> 
>> If you're talking about using the Lua interpreter to receive data by
>> executing incoming data as code and dumping out the Lua tables found
>> in the interpreter afterwards... in addition to the obvious hazards of
>> making things executable that shouldn't be, this is a very expensive
>> and ass-backwards way to avoid writing 500 lines of parsing code, and
>> I don't see the point.
> Seconded.
> I like Lua. I used it at work for some prototyping stuff. This also
> included using the Lua C-API. It is quite cumbersome to use a full
> blowen script interpreter API only to extract some data values.

That full blown script interpreter is 64K, btw.  But anyway, you point is 
valid, of course.  If you program, otoh, uses Lua anyway for scripting 
purposes, then this becomes a non-issue.

> An other point: If configuration is kept in Lua you _have_ to mangle it
> through the Lua interpreter. There is no other way of retriving the
> data then executing the script and extracting the data from the Lua
> state afterwards. There is no way to process the configuration Lua
> script in e.g. Perl, tcl, Java, Lisp, Haskell, Fortran, ... just by
> parsing. You have to bind the Lua C-interpreter to that foregin language
> or you have to reimplement the Lua language in that non-C language.
> Sorry. I am not going to by this.

Yes, there is no way around that executing it.  But we are talking about a 
configuration/data exchange system for NetBSD programs, and fortunately not 
many of them are written in e.g. Perl, tcl, Java, Lisp, Haskell, Fortran...  So 
this argument is nothing more than FUD in this context, it's actually 
irrelevant for the problem at hand, because those languages are just not used a 
lot in NetBSD.

> At work we use JSON and made good experience with it. It supports just
> the right value types needed (number, string, bool, nil) and these can
> be combined to arbitrary complex objects by enumeration (JSON-Object)
> and iteration (JSON-Array). There are good JSON libraries for a
> gazillion of different programming languages including bash...

JSON is a practical thing as well.  I would not be to much surprised if some 
programs would use JSON for data exchange (as much as I am convinced that some 
will go the Lua route).  It would even per interoperable, as Lua can, using a 
JSON module, easily parse JSON data.