[Easyb2k-devel] Application Structure

[Thomas R. <tre...@ya...>]

Hi,=0Aafter reading through the various emails I missed before, I have a fe=
w=0A comments / suggestions / thoughts:=0A=0A* Using D-BUS instead of UNIX =
sockets sounds like a good idea. Using=0A David's drawing the structure wou=
ld look like=0A=0A  VoIP application=0A        ^=0A        |   (any protoco=
l, depending on VoIP application)=0A        v=0A  Glue Software (most likel=
y a separate component, like gnomemeeting=0A connector)=0A        ^=0A     =
   |   (D-BUS)=0A        v=0A  Our Daemon=0A=0A* Also I love the idea of us=
ing HAL, it provides enough information for=0A the daemon to load the appro=
priate low-level device plugin (i.e.=0A libyealink) and notifies the daemon=
 about new or removed devices. The retrieval of the serial number (or any o=
ther distinctive value) could then be implemented in the driver plugin.=0A=
=0ANow a question:=0AYou discussed that there could be a "single device" mo=
de (i.e. grab the one device available) and a "multi-device" mode, which re=
quires a command-line argument to the daemon or, if missing, asks for for i=
t.=0ANow what I am not 100% understanding in this setup is:=0A1. Who starts=
 the daemon, i.e. who is responsible for supplying the command-line argumen=
t?=0A2. How can a user select the right device without diving into the guts=
 of some startup file?=0A=0AWhat I have in mind would be a daemon which con=
sists of the following components:=0A=0Aa. The daemon core which is only re=
sponsible for =0A   - providing the D-BUS object any glue initially connect=
s to=0A   - tracking available devices via HAL=0A   - dynamically loading t=
he device plugin depending on HAL's device properties=0A   - spawning a dae=
mon device manager (see b.) for a specific device by request of glue softwa=
re=0A   - providing a list of available devices by request of glue software=
=0A=0Ab. The daemon device manager, which is instantiated for each device w=
hen it is requested by glue software and which=0A   - provides the main D-B=
US interface for the phone functionality on one side=0A   - talks to the de=
vice plugin on the other side=0A   - could also implement DTMF or Bell 202 =
signaling if required by phone (implementation detail)=0A   - also (via D-B=
US) provides information about configuration parameters and methods for set=
ting/getting these parameters (Note: The parameters depend on the selected =
phone model.)=0A=0AThe device plugin(s) could have the following tasks:=0A-=
 provide a defined interface to the daemon, including advertising some low-=
level capabilities if that makes sense for easier implementation of the dae=
mon device manager=0A- provide a unique ID for a specific phone to be passe=
d on all the way up to the glue software to later identify the phone=0A- im=
plement the low-level USB calls to the device.=0A=0AWith this infrastructur=
e the glue software would register with the daemon core and if it does not =
know about a previously selected specific device, ask the daemon core for t=
he first available device. It could also prompt the user to select one of t=
he available devices. If the glue software has found an already selected de=
vice ID in its configuration, it could ask for that specific device only.=
=0AFrom this point on it would only talk to the newly created daemon device=
 manager about configuration parameters and then about the general phone op=
eration.=0A=0ADid I miss KISS?=0AIs this too complicated, is there a simple=
r structure allowing similar convenience like SkypeMate?=0A=0ARegards,=0A-T=
homas=0A =0A=0A=0A      Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: =
=0Ahttp://de.yahoo.com/set