[lcdproc] FW: version 0.4/0.5?

[William W. Ferrell]

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

--- andreb@rd.bbc.co.uk's mailer spewed these beefy chunks ---
> On Mon, 19 Mar 2001, David Glaude wrote:
>=20
> But how do you deal with "backports" from 0.5 to 0.4 after the final 0.4
> (0.4-post1 ?) ?

I doubt it'll be worth the effort. If we actually pull this off
properly, v0.5 will be a much-desired upgrade; I'd like it to *fully*
support everything v0.4 did then add some more and still be easier to
develop for. v0.4 will hopefully become an unsupported old version.

> >  * Solaris port.
>=20
> As I can see the server itself is working on SunOS 5.7 .

Yes, but the client that pulls CPU/net/disk/etc. stats didn't work on
Solaris. Thanks to Chris Debenham, it does now :)

> >  * Gather all the patch from everybody and integrate them.

> Good idea. So should send my pending stuff:
>  Bugfix to MtxOrb
>  Question(s) for protocol changes

Can you elaborate a bit on that MtxOrb bug?

Also (if you've already given me this, it's okay to smack me while I get
organized again :) can you send along your sourceforge ID so I can add
you as a developer, at least to track these todos.

I'm still sorting out the protocol changes. I started a document about
this several months ago I need to dig up -- there were some decent ideas
in there.

=46rom what I recall, we decided to go with a human-readable (or at least
human-decipherable :) protocol, in the clear (for now, adding support
for SSL later) communication except for the initial authentication
(shared secret unless somebody seriously feels like implementing
public/private key for this monster :).

The current protocol is totally unacceptable. The server needs to be
able to transmit precise display capabilities to the clients, be more
"informative" for inquisitive clients (what are you running on? What
version are you? What options are you running with? How many displays
have you got?), and so on. Thus, it won't be backwards compatible at all
with the current protocol. Clients will need to be updated to deal with
it. Some may require rewriting. Too early to tell for now.

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

Public key available:
  gpg --keyserver certserver.pgp.com --recv-key 7478FC7A

Charity, n.:
	A thing that begins at home and usually stays there.

--UoPmpPX/dBe4BELn
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iEYEARECAAYFAjq2FRQACgkQgAeqhXR4/HoLIQCgotAENwlXVfXxx34mI/ubyJF6
M6oAnilZkG6mG0rAavzLs/LZ6dro2Kqc
=8DjX
-----END PGP SIGNATURE-----


--UoPmpPX/dBe4BELn
Content-Type: text/plain; charset=


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