[lcdproc] TCP or .so

[William W. Ferrell]

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

--- joris@robijn.net's mailer spewed these beefy chunks ---
> I've changed the subject line.

Hehehe probably a good idea.

> > Windows can do either dynamic loaded modules or network connections,
> > correct? Neither of those ideas were dissed, so let's build around using
> > either/both of those for the Unix versions too. That way we don't have
> > to have millions of #ifdef's everywhere, swapping whole chunks of code
> > in and out, just smaller bits where the functions or prototypes are
> > different between OSes.
>=20
> Both will not go I'm affraid. we will need to choose here, because TCP=20
> connections require separated processes, and that changes the=20
> 'independance' of the drivers a lot. For example, when using .so, the=20
> driver will be called 8x per second by the core of LCDd to update the=20
> LCD. When using separate processes, the driver-process needs to=20
> generate it's own 8Hz update. We cannot choose to do both I think. We=20
> could default to .so and use TCP as an alternative connection method.

I agree. A decision needs to be made for one or the other of our
options, then throw the other by the wayside until we finish getting the
first one right.

> > I still dynamic modules are the better way to go, far more tidy on the
> > system, and far less likely to be sabotaged in a security exploit. Look
>=20
> Using only one and the same small parser in LCDd and drivers should=20
> limit the posibility of exploits.

Very true. I fully expect drivers and clients to include bits of LCDd=20
(namely the parser and socket library). Except of course when they're
not written in C :)

> > other thing is maintaining synchronisation between LCDd and the drivers,
>=20
> When they should have lost connection, they can try to reconnect. If=20
> that succeeds, LCDd should send the contents again, so they get 'in-
> sync' again. LCDd knows how to 'place' the various displays (above,=20
> next etc), so when a 'lost' driver reconnects LCDd should recognize it,=
=20
> and it will place it back where it belonged. Are there other problems ?

Have we even firmly decided yet whether we're going to send full
framebuffers every frame or just deltas?

Keep in mind that the screens (by default) are rotated every five
seconds; so even if we just sent deltas, a screen would only be ugly for
five seconds until a full screen redraw came down the pipe (I think for
each screen change, a full redraw should be sent).

> About security, I think we should not forget that we have an TCP-
> interface already, and using it for something extra will hardly=20
> increase vurnerability (at least if we use only one small parser).

Heh. Yeah, we've got enough exploits available as it is :)

> > Another point is memory space. I seem to remember a few people being
> > pro-embedded here. Imagine an embedded system running LCDproc with four
> > displays connected. Using methods other than modules, you'll have 5
> > executables running on that system, with modules, you'll have one
> > executable and a bit of extra object code loaded once.
>=20
> And LCDproc clients, not to forget. That's the case already since v0.4.=
=20
> But the clients need to be separate I guess. Good point nevertheless.

There was some discussion awhile ago about making an embedded-optimized
version of LCDd. One benefit of using TCP/IP to communicate between the
drivers and the server is that only the physical driver would have to
sit on the embedded device (assuming it had network connectivity).

> > I perhaps get the idea that some people are put off simply because they
> > don't know how to code this sort've thing. I have already started
> > knocking up the interface for this, and would be happy to maintain this
> > part for the 0.5 release. THerefore everyone doesn't need to know *how*
> > it works right away as long as they admit that it *does* work! Anyone
>=20
> I beleave you :)

Hehehe yup me too :)

> I like the 'spider in the web' idea of LCDd between the clients and the=
=20
> drivers, mostly because its design looks so elegant I guess. Maybe that=
=20
> should not be an argument. Of course you're right, modules have many=20
> advantages too, and the decision is getting more difficult by the=20
> minute, if you ask me. The arguments for both alternatives seem to be=20
> balanced. (if we go .so, TCP might stay available as an alternative=20
> connection methode)=20
>=20
> Should we vote or something ?

Nah, there haven't been any violent arguments yet to give us an excuse
to force an election :)

> In case we go TCP, I offer to write a small robust parser that takes=20
> care of the communications. If it were just to balance Matt's offer ;)

Coolness. We'll need that robust parser anyway for client<->server
communication anyway :)

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

Think twice before speaking, but don't say "think think click click".

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

iEYEARECAAYFAjq7tVgACgkQgAeqhXR4/HrG9gCgi2KPxUnyGZTBrAA3pPT+S5id
kFYAn34ajwO+LzvMuPYDYqUIwZETFPpi
=B+6O
-----END PGP SIGNATURE-----


--+SfteS7bOf3dGlBC
Content-Type: text/plain; charset=


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