New lircd design (Was: Raw codes and toggle bits)

[Alec L. <lea...@gm...>]

On 29/07/16 10:17, Alec Leamas wrote:

> On 27/07/16, Bengt Martensson wrote:
>>
>> I have written most that I have to say in the article. Update: The
>> "(presently not published) simple dispatcher in Java" is this one:
>> https://github.com/bengtmartensson/dispatcher
>>
>> I am not sure if/how Alec's front/backend maps to my terminology.
> In short, the frontend more or less completely matches the dispatcher. 
> The backend is a combined listener/sender thing. However, there could 
> be multiple backends. Stay tuned for now, will push a branch later for 
> discussion.

I have pushed a WIP branch called ng. It's by no mean functional, just a 
preliminary hack. The state could be described as "works occasionally".I 
will not be able to work with this for some time, so here are some 
comments for those interested (including myself once I return to this):

The basic idea is to split the lircd  monolith to a single frontend 
called lircd and one or more backends. The frontend, a k a dispatcher, 
preserves the current client interface.

Each component is a separate process, communicating over sockets just as 
today.

The main dispatcher lircd.cpp  is in a reasonable shape. It has a file 
comment describing what it is doing.

*lircd-backend-tcp* is a simple backend  implementing the --listen 
option. It's used to pioneer the backend interface.

*lircd-backend-std* is  the remaining parts of current lircd 
implementing a backend. The combination of  lircd + a single 
lircd-backend-std should be identical to current lircd.

*irtool* is a new tool aimed to export the complete new control socket 
interface. irtool -h gives a hint. It's the only user tool which is 
aware of the different backends.

*dummy-backend* is a expect/tcl test tool .

There is no documentation whatsoever. The objectives includes to make it:

     - Easier to respond to hardware changes by starting a backend, 
typically in a udev rule.
     - Easier to use multiple devices simultaneously.
     - Possible to re-implement the backend with completely new ir 
rendering while still staying API compatible.
     - More testable.


Cheers!

--alec