config language

[John van Vlaanderen]

Hi, 
Years before XML, In perl, I developed a kind of complex structure to
store user state information at the NY Stock Exchange for if/when the
systems went down all the users could be restored to what they were
doing beforehand.

Later I wrote a dataserver which accepts something like a URL string
with a serialized data structure on the end of it, freezes it to disk
and the returns an sub or super set of that structure in serialized
form.  I think created a way to put code in it as text, and now I have
promised myself that I will actually embed code in them someday.

XML came along and showed how inefficiently this could be done.  I think
the parsing complexity is becasue it is a markup language and has
attributes and stuff that are comical by normal language standards.

I went to a lisp meeting last night, and suddenly realized I had been
using lisp to teach perl to kids...  now I wish there was a C-Lisp-AN.

I think perl structures are about as readable as a config can get,
though there is a slight learning curve.  I am also wondering how
Perl6's Parrot VM can be integrated into LinuxBIOS.

Here is a quick tutorial for perl with structures that I wrote,
http://thinman.com/perl_primer/

John

 
On Wed, 2003-05-21 at 11:03, prl-linuxbios at sychron.com wrote:
> > This is functionality we need in the LinuxBIOS table especially
> > for devices that cannot be detected by the OS.  Like temperature
> > sensors.  This should be easy to add in the 1.1 development tree.
> > 
> > This is information we cannot transmit via DHCP.  A DHCP packet
> > is to small.  In DHCP we just need enough information to bootstrap.
> 
> I was not suggesting that the tables must of necessity all be munged
> into a DHCP packet, though I observe that with a reasonable encoding,
> most descriptions probably *would* fit in a single DHCP options field of
> 312 bytes. In practise I agree that one would use only those parts which
> were relevant to (network) booting in a real DHCP packet.
> 
> But... reading through the recent discussions about XML, it took me some
> time to release that people were talking about parsing IN LinuxBIOS, as
> opposed using XML as an input file to a build or config process. XML or
> similar in LinuxBIOS itself seems like overkill to me.
> 
> Please consider using DHCP encapsulated option format as an internal
> format for LinuxBIOS in the first instance, even if DHCP (the protocol)
> is not used. I see several reasons...
> 
> - Compatibility with the DHCP protocol
> 
> OK, I understand that not everything wants to use DHCP for network
> configuration, but even the most ardent boot-from-the-bare-metal
> embedded fan must appreciate that many do use DHCP, even if only for
> testing code via DHCP / TFTP before a final product is burned in.
> 
> Or, put another way, why would you make a *point* of being different?
> 
> - Code exists
> 
> DHCP option parsing code exists in Etherboot (so Etherboot-on-LinuxBIOS
> users have it anyway). As I say, a hardware description has been
> discussed (and I *think* implemented) in Etherboot in the particular
> case of PCI nics.
> 
> - Compact parser and encoding
> 
> DHCP hardware descriptions (i.e. individual chipsets) should be encoded
> numerically. There are reasons why existing DHCP options and SNMP MIBs
> do it this way - 32 bits encodes a HELL of a lot of possible hardware
> types in only 4 bytes. Doubtless someone will tell me that DHCP isn't
> the most efficient method or that they have a *really* neat parser for
> their favourite format. Big deal - refer to "Code exists".
> 
> - Do the hard stuff outside LinuxBIOS
> 
> Register the encodings centrally held table (like other DHCP options or
> an SNMP MIB), so that when building, tables can be built as appropriate
> from XML definitions. A DHCP server or a small amount of perl in the
> build process can translate raw numbers to and from human readable form
> using boilerplate derived from the central table. Where possible (e.g.
> PCI IDs), use an existing registry anyway.
> 
> 
> _______________________________________________
> Linuxbios mailing list
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios