[lcdproc] TCP or .so

[David Glaude]

Hello,

Being the one that started to talk about named pipe...
I must officialy announce that I am convince with ".so" solution.
Dynamic loading of driver is not a MUST HAVE for me and since we can
staticaly link too
(for Windows?, for embeded, for ???) it offer all the simplicity/portability
we require.

Serial communication accross TCP, named pipe, and all special trick or nice
to have,
can be implemented as an alternate driver.

One of the NICE TO HAVE feature is to make sure our driver
(Matrix Orbital, Cristalz, HD47..., other) can be reuse by other project.
This could be either reusing the .so or using some of our code (widget) +
.so.

Having separate process was reducing the security issue due to priviledge
require
to write to the hardware... but was introducing yet place where the
parser/protocol
need to be strong. Now if we go for the .so solution, then I don't know how
to deal the the security risk/fear of having suid root process.
As far as I know root is not requiered for serial based LCD, so parallel
port
LCD driver introduce special requirement. I would like it possible
to compile a LCDd that do not require suid root if I only use Matrix Orbital
LCD.

I am pretty sure many project would love to have an LCD output without
having to take care of this part. The best would be to create a library
of function to help peaple write LCDd client code.
And in this library of function they can choose the
multiclient/multiscreen/multiplex
over TCP way or they can use the stand-alone/embeded/driver linked way.

This does not answer the question about where should the framebuffer be,
where should the widget be implemented. In my mind, the driver code 
should be minimum in size to reduce the price to pay (time to develop)
when someone wants to write a new driver. Basicaly, I know my hardware,
I know the protocol, I know how to talk to my hardware so it should be
easy to write a driver for LCDd. Once I have a driver for LCDd I know
a lot of project will be able to support/use my hardware.

About parsing, we basicaly need something for the protocol (over TCP)
and the configuration file of LCDd. I believe in KISS concept and avoiding
lex/yacc should be possible for simple task like that.

Also I don't know yet either how to deal with "keys" and keypad...
Just make sure LCDd is easy to use for stand-alone client.
I think if client/process need to share some input, then they need
to some how colaborate for this.

Futur or possible new feature???

Did anybody thinked of using message passing inside LCDd?
Like: A driver could send a "key-pressed" message to LCDd
and LCDd would pass the message to other client.
This would let a client "control" another client.

Also, what about dynamic (TCP) connection of "watcher" or "driver"?
Someone connect (telnet?) and say, "gimme a copy of the screen (TXT or VT100
or cursus)".
That would be a nice way to be able to remotely "see" the LCD.
Also it could be use for a web screen shot of "currently on my LCD".

David GLAUDE


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