[lcdproc] XML discussion
William W. Ferrell
Fri, 25 Aug 2000 08:54:04 -0600
Content-Type: text/plain; charset=us-ascii
* Jon (email@example.com)'s mailer blew these chunks:
> > Hmmm... some good arguments for text instead of binary. Dammit :)
> > Somehow even though I've been preaching for the past day that "hey! We
> > could just compress the XML data in the protocol!" it didn't occur to me
> > that we could just do the same thing for text.
> > So the server does text, then if bandwidth is a concern, it can use
> > compression. A tempting idea. That adds some more config entries, too :)
> > [server]
> > allow compression =3D yes # Allow clients to request a "gzipped=
> > recommend compression =3D yes # Tell clients "gzipped" sessions are=
> > force compression =3D yes # Compression *must* be used; clients=
> > # not support compression will not be
> > # allowed to connect.
> Yes, that is a good method..
> that way for those of us using LCDd with embedded apps, we can allow gzip
> but not require it.
> also, i think the 'recomend compression' isnt really needed.
Actually, I think it'd be useful for instances where an administrator
*wants* compression to be used wherever possible but doesn't want to
exclude clients that don't support compression. A rare case, but one we
can support for free :)
> The server should announce what features are on/supported (in a
> version/feature line?) and the client can choose itself
> For instance (made up situation)
> ~$ telnet localhost lcdd
> Escape char is ^]
> LCDd: v 0.5a1
> FEATURES: Char 20x4 , custchar , gzip , bklite , flash
> then you send user/pass, OR send the command to enable gzip and send the
> user/pass gziped afterwards..
> The options listed above are sent mostly by the driver (not all screens
> will support custom characters, or backlighting, etc)
> with this sort of method, if the tag is there, the client CAN store it and
> use that info smartly..
> granted a client can still send a command such as flash when there is no
> flash support (or its disabled) however it will just be ignored
> (Hows that for embedded memory usage?)
Should be pretty good for embedded systems, methinks :)
"Oh look, a valid but unsupported directive. [Drop]."
> smarter clients with more resources available can store those options and
> make descisions based upon them
> or even, have a command that requests features, and the features line is
> only sent then.. that cleans up the connection to the server a tad, and
> lets embedded clients totally not ask for that info, and not waste
> bandwidth having to see it..
Yes, this is good. The protocol specification should require (or at
least highly recommend) a client fetch the feature list, and in return
guarantee that the server won't just spew loads of data at the client
immediately on connect.
> it also lets us expand later, to where no client needs to assume xxx lines
> of text will be jammed down its throat on connect.. just assume 0 lines
> then you can (in text) request features, or even specifics
> -> FEATURES
> <- FEATURES: Char 20x4 , custchar , gzip , bklite , flash
> -> FEATURES gzip
> <- FEATURES: gzip 1
> (or 0)
This is pretty good.
> so you can do the gzip thing first, then After that, grab the full list of
> features using whatever encoding that was decided on..
> > So what would your config file look like then, using an XML-like layout?
> > Have a look at my previous message for my example config file...
> > hopefully those are sane options.
> > And what would we do to parse it?
> well, as you have most of it typed out in ini format.. and i really
> havent put too much thought into it
> basicly would be similar with options such as
> <set keyword> yes
> <set other_keyword> no
> but i have no idea how to parse decently..
> (Ive never made an xml-ish config for any of my programs)
> Heres my opinion, if your comfortable coding for the ini style, and it
> would be less hassle to use, then do that..
> Personally, i wont care what type of config you decide on and use, and i
> will use whatever that is..
Heheheh okay. I'm not opposed to using the XML-ish format so long as we
can sort out how to parse it.
I know I seem really "keen" on using .ini-style, but only because I have
a decent idea how to parse that myself already. If someone else can come
up with a better idea (and some suggestions how to parse), begin spewing
William W. Ferrell, System Administrator, Global Crossing Ltd.
950 17th St Ste 2200, Denver, CO 80202 1.303.223.0564
But it does move!
-- Galileo Galilei
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
Content-Type: text/plain; charset=
To unsubscribe from this list send a blank message to