Re: [Easyb2k-devel] Application Structure

[Daniel R. <dr...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Reitmayr wrote:
>   VoIP application
>         ^
>         |   (any protocol, depending on VoIP application)
>         v
>   Glue Software (most likely a separate component, like gnomemeeting
>  connector)
>         ^
>         |   (D-BUS)
>         v
>   Our Daemon
	Originally my idea was:

        VoIP app
            ^
            |   (any protocol, preferably D-BUS)
            v
- ---------------------------
|      Glue PLUGIN        |
|           ^             |
|           |   (libdl)   |----> Our Daemon
|           v             |
|      Daemon Core        |
- ---------------------------

	All GPL software will most likely use a "standard" protocol using D-BUS
as transport, but the glue on a plugin keeps it flexible enough to
support everything else.
	The Daemon Core needs to support _multiple glue plugins_, to allow us
to use N Voip applications with one hardware device.

> Now a question:
> You discussed that there could be a "single device" mode (i.e. grab the one device available) and a "multi-device" mode, which requires a command-line argument to the daemon or, if missing, asks for for it.
> Now what I am not 100% understanding in this setup is:
> 1. Who starts the daemon, i.e. who is responsible for supplying the command-line argument?
> 2. How can a user select the right device without diving into the guts of some startup file?
	Config files should only be avoided on the "typical" use case. eg *one*
device. (in fact, a config file would be used even when just one device
is connected, but with a "broad" default configuration, that tries every
glue supported).
	People using more than one device would use a .conf file for each
device, and run multiple instances of the daemon, each using a different
.conf.
	There is no way to guess what VoIP applications the user wants for each
device, nor the order at which HAL will call the daemons, so, for the
multiple device case we cant escape the manual configuration.
	A variation of this idea would be using the same config file for all
the daemons, and defining config sections with the box serial number as
index, this way the daemon can decide which section to use.

- --
Daniel Ribeiro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHJ+59w3OYl0G0liQRAvLpAJ48CUnZhgqU5TGo1VohqYY53HeQeACggUjv
hNHKooyt0tKJqiFmC0GpWpg=
=x31O
-----END PGP SIGNATURE-----