[lcdproc] TCP or .so

[Joris Robijn]

> 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 
core-->client)

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


-- 
 Joris Robijn <joris@robijn.net>
 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
lcdproc-unsubscribe@lists.omnipotent.net