[lcdproc] TCP or .so

[Joris Robijn]

> 
> That works, but then the drivers have to understand and implements all
> the widgets. If we decide to add new widgets to LCDd, now we have to
> update all the drivers instead of just releasing a new LCDd :)

Hmm, yes. In the current implementation it's a bit half-half. There's 
some stuff in the driver (creation of V-bar userdef-chars) and there's 
something on the LCDd core side (the actual drawing of the bar). That 
means that in the current implementation we need to change both (for 
example if we add a graphical display). I think that is not optimal.

> > And for the embedded systems, we can produce something that links
> > one=20 client directly to one driver (without LCDd) into one
> > executable. That=20 might be possible because the language is the
> > same, and there is no=20 multiplexing needed when you have only one
> > client and one driver.
> 
> A very good idea. If we decide the above issue (drivers handling widgets
> instead of LCDd) is worth dealing with, this would be a definite win.

Yes _if_. Can some other people comment on this subject ? (I know it's 
weekend now, so it will probably take some time.)

> Do 'ya know how to build such a parser, though? I sure don't :)

The driver has on init supplied the parser a table with pairs of start-
keywords and pointers to functions. The parser scans the input line for 
start-words and then for parameters (PARAMETER="string" or PARAMETER=12 
(number) etc ). After a line has been processed, these parameters are 
stored inside the parser. Then the function is called from the table. 
The function can then read-out the parameter table by using a get-
function from the parser. For example it can do a 
get_parameter_int("size",defaultval). The return value will then be the 
SIZE parameter, or if it was not specified the defaultval value. This 
is a very small parser, and it's easy to use by programmers of drivers. 
It has a good degree of encapsulation, you need the function to 
retreive values. 

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