[lcdproc] LCDproc v0.5 development, here we go folks :)

[William W. Ferrell]

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

* Eric Z. Ayers (eric@compgen.com)'s mailer blew these chunks:
> William W. Ferrell writes:
> ...
>  > Oh, I *REALLY* like this. An XML-based protocol.
>  >=20
>  > This would actually make sense, I think. The only thing missing here is
>  > interaction with the server. These widgets get defined initially, but
>  > then how doth the server request and receive updates? Something like
>  > this, perhaps?:

[snip]

> yup.
>=20
> That's another reason why you might want to use XML.  You don't really
> want to spend time writing the parser yourself.  There are free
> libraries  out there to do that, that you could just include in the
> source distribution for lcdproc  (I'm thinking gnome libxml for 'C'.)

I'm digging into that now.

> XML parser are very persnickity.  It is POSSIBLE to edit a file by
> hand, but one screwup and the parser isn't very forgiving.  There is
> none of this lazy tag with no closing tag that HTML allows (I wouldn't
> say HTML is wrong, it's just not as strict)

So do you think it's worth making the end-user config file XML then? Or
will people have trouble with it?

>  > <lcdproc>
>  >    <server>
>  >       port =3D 54
>  >       max clients =3D 10
>  > Am I going in the wrong direction with this, or does the above seem
>  > feasible?
>=20
> It's feasable, but I think you'd just want to use the XML parser stuff
> and not sub-parse the stuff inside.  I've been down this road before
> with the DENTS project.

Okay, so (merging in another comment a bit ago about XML simple tags):

<lcdproc>
   <server>
      <port value=3D"54"/>
      <max_clients value=3D"10"/>

=2E..

Would that be better/easier to parse?

>  > ...  I must say I like this XML idea. Too
>  > bad it'll probally add a good chunk of time to the development
>  > cycle :)
>=20
> Only if you write your own parser, (which doesn't sound like a good
> way to spend time)

If libxml is portable enough, we can just use that. End o' problem :)
Start of others (namely, using the parser properly ;), but that's okay.

--
William W. Ferrell, System Administrator, Global Crossing Ltd.
950 17th St Ste 2200, Denver, CO 80202   1.303.223.0564

"Never give in.  Never give in.  Never. Never. Never."
-- Winston Churchill

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

iEYEARECAAYFAjmlOt4ACgkQgAeqhXR4/Hq+MgCgvmRsq5HclyozCAr7WI8oKDu6
YoYAn0V6W5g0mhMlimbRru3+W5lyaP8u
=A5y/
-----END PGP SIGNATURE-----


--d6Gm4EdcadzBjdND
Content-Type: text/plain; charset=


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