[lcdproc] TCP or .so
Mon, 26 Mar 2001 17:12:57 +0200
> I think the easiest way is the one with shared libs (.so,.dll,.library
> ...) bacause yu can use funtion calls and pass complete structures to
> the client. On platformes without shared library support it's possible
> to link the driver into the daemon (same as in 0.4).
We're not passing structures in the current version...
> If we like to use same sorte of distributed drivers (via TCP,
> UDP+multicast, X25 ...) we can write a driver lib which serialises the
> function calls + mem structs and sent this to the driver (which consists
> of the real driver and a app for conversation from serialised -> fuction
> call + mem struct). Yes I know this is the same as RPC/RMI.
I think we can use the language as
1) screen contents description (client-->core-->driver)
2) setting attributes (backlight, contrast etc core-->driver)
3) menu defining (client-->core)
4) event passing (keybdriver-->core, keybdriver-->client, and
So that would be more than RPC/RMI.
> Yes limit, but we open a potential hole.
It can't be worser that it is right now ;)
> But the LCDd can't figure out if this new connection belongs to the same
> driver which is allready known (and has died) or a new one (or we need a
> constant unique id per driver).
Oh I would like that! That means that you can set its parameters in the
config file too, because you can specifiy the ID in the config file.
> You can't rely on the connection (high latency, small bandwith, data
> loos, ...).
Jep. Delays should have no influence.
Joris Robijn <email@example.com>
Home: 053 4311 553
Mobile: 06 288 41 964
// To understand recursion, we must first understand recursion
To unsubscribe from this list send a blank message to