[lcdproc] XML discussion

[William W. Ferrell]

--76DTJ5CE0DCVQemd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Jon (dissy@netset.com)'s mailer blew these chunks:
>=20
> > 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.
> >=20
> > 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 :)
> >=20
> > [server]
> > allow compression =3D yes         # Allow clients to request a "gzipped=
" session
> > recommend compression =3D yes     # Tell clients "gzipped" sessions are=
 preferred
> > force compression =3D yes         # Compression *must* be used; clients=
 that do
> >                                 # not support compression will not be
> >                                 # allowed to connect.
>=20
> 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.
>=20
> 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
>=20
> For instance (made up situation)
> -----
> ~$ telnet localhost lcdd
> Escape char is ^]
>=20
> LCDd: v 0.5a1
> FEATURES: Char 20x4 , custchar , gzip , bklite , flash
> -----
>=20
> 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..

Right.

> 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
>=20
> 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
>=20
> ->  FEATURES
> <-  FEATURES: Char 20x4 , custchar , gzip , bklite , flash
>=20
> ->  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..
>=20
> > 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.
> >=20
> > And what would we do to parse it?
>=20
> well, as you have most of it typed out in ini format..  and i really
> havent put too much thought into it
>=20
> basicly would be similar with options such as
>=20
> <server>
>  <set keyword> yes
>  <set other_keyword> no
> </server>
>=20
> but i have no idea how to parse decently..
> (Ive never made an xml-ish config for any of my programs)
>=20
> 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
now. :)

--
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

--76DTJ5CE0DCVQemd
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjmmiIwACgkQgAeqhXR4/HpGhACbB236vcHDtsTpEc/1kQIKeL1D
9TAAoOJxhYT5RDYhURdydnjKcK4U6ygJ
=Qp+U
-----END PGP SIGNATURE-----


--76DTJ5CE0DCVQemd
Content-Type: text/plain; charset=


-----------------------------------------------------------
To unsubscribe from this list send a blank message to
lcdproc-unsubscribe@lists.omnipotent.net
--76DTJ5CE0DCVQemd--