Thread: [Easyb2k-devel] Application Structure
Status: Pre-Alpha
Brought to you by:
wyrm
Menu
▾
▴
easyb2k-devel
|
From: Thomas R. <tre...@ya...> - 2007-10-30 17:10:07
|
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 |
|
From: Marcos <ma...@un...> - 2007-10-30 20:38:33
|
Hi! First of all, I belive the yealink devices can be abstracted to a generic yealink devices, with capabilities. Thomas did a great job on his libYealink about that. Our design is by now it extremely complicated. Skypemate is simple because it just work with one device at the same time. If you plug two devices, it will just pick one at random and ignore the other. Therefore you can not have two devices on the same machine. I don't like that. Nevertheless you can have more glues (SkypeMate,YahooMate, etc ) on the same machine. The user just load the specific WHATEVERmate, and whichever gets loaded first "owns" the device. In such a scenario, there is always one device and one glue, so the choice is trivial. I don't like that either. Now how are going to manage multiple devices and glues without a configuration file ? I can not see any simpler design than: 1) The user plugs a device. 2) The daemon is automatically launched. 3a) If there is just one device and one VoIP program, the specific glue is loaded with the device as a configuration. ( a VoIP ping should be implemented by the glues....) 3b) The daemon gets the device's serial number and launches/loads the right glue (informing which device the glue should use) according to the configuration file. Notes: - If the glue talks to the device thought the deamon, it will talk through a generic device, with capabilities. - If the glue talks directly ( and I can not see a reason for that, the daemon closes ) To make things simple for the user, a configuration program could be implemented and pop up whenever the second device gets plugged. We could have two special devices called "GLUE DISABLE" and "ANY DEVICE". Any newly installed glue will be by default connected to the "any device" device. I still have not seen/understood anything simpler.... Daniel, your suggestion does not handle multiple glues per device. By the way, I implemented a program called lsYealink, which list the yealink devices. It is in the SVN. (sf.net/easyb2k) Thomas, please upload libyealink to the svn, so I can add my code to it. Marcos --- Thomas Reitmayr <tre...@ya...> schrieb: > Hi, > after reading through the various emails I missed before, I have a few > comments / suggestions / thoughts: > > * Using D-BUS instead of UNIX sockets sounds like a good idea. Using > David's drawing the structure would look like > > VoIP application > ^ > | (any protocol, depending on VoIP application) > v > Glue Software (most likely a separate component, like gnomemeeting > connector) > ^ > | (D-BUS) > v > Our Daemon > > * Also I love the idea of using HAL, it provides enough information for > the daemon to load the appropriate low-level device plugin (i.e. > libyealink) and notifies the daemon about new or removed devices. The retrieval of the serial > number (or any other distinctive value) could then be implemented in the driver plugin. > > 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? > > What I have in mind would be a daemon which consists of the following components: > > a. The daemon core which is only responsible for > - providing the D-BUS object any glue initially connects to > - tracking available devices via HAL > - dynamically loading the device plugin depending on HAL's device properties > - spawning a daemon device manager (see b.) for a specific device by request of glue software > - providing a list of available devices by request of glue software > > b. The daemon device manager, which is instantiated for each device when it is requested by glue > software and which > - provides the main D-BUS interface for the phone functionality on one side > - talks to the device plugin on the other side > - could also implement DTMF or Bell 202 signaling if required by phone (implementation > detail) > - also (via D-BUS) provides information about configuration parameters and methods for > setting/getting these parameters (Note: The parameters depend on the selected phone model.) > > The device plugin(s) could have the following tasks: > - provide a defined interface to the daemon, including advertising some low-level capabilities > if that makes sense for easier implementation of the daemon device manager > - provide a unique ID for a specific phone to be passed on all the way up to the glue software > to later identify the phone > - implement the low-level USB calls to the device. > > With this infrastructure 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 the first > available device. It could also prompt the user to select one of the available devices. If the > glue software has found an already selected device ID in its configuration, it could ask for > that specific device only. > >From this point on it would only talk to the newly created daemon device manager about > configuration parameters and then about the general phone operation. > > Did I miss KISS? > Is this too complicated, is there a simpler structure allowing similar convenience like > SkypeMate? > > Regards, > -Thomas > > > > Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: > http://de.yahoo.com/set > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Easyb2k-devel mailing list > Eas...@li... > https://lists.sourceforge.net/lists/listinfo/easyb2k-devel > |
|
From: Daniel R. <dr...@gm...> - 2007-10-31 02:48:17
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marcos wrote: > Now how are going to manage multiple devices and glues without a configuration file ? There is no reliable way to manage multiple (and equal hardware) devices without manual configuration. > I can not see any simpler design than: > 1) The user plugs a device. > 2) The daemon is automatically launched. 3a) If there is just one device, the default configuration tries to load every supported glue, the glue pings the VoIP app only at the probe() function, if it fails the core daemon unloads the unnecessary glue plugin. This will work with *one* device and *N* VoIP applications. 3b) If there are multiple devices, the core daemon looks for the specific device configuration, if it fails to find, the core daemon exit(). If it finds a suitable configuration, it loads the glues according to what the user configured. > To make things simple for the user, a configuration program could be implemented and pop up > whenever the second device gets plugged. We could have two special devices called "GLUE DISABLE" > and "ANY DEVICE". Any newly installed glue will be by default connected to the "any device" > device. A configuration GUI could be implemented, to allow generic configuration, the default configuration will handle most use-cases but some people (even with just one device) will eventually want to "fine-tune" something. ;) > I still have not seen/understood anything simpler.... Daniel, your suggestion does not handle > multiple glues per device. One core Daemon can load N glue plugins. Each device connect event triggers HAL, which loads one instance of the core daemon. In the end it supports N devices, connected to X glue plugins, through N instances of the daemon, and, of course, X has to be greater than N. - -- Daniel Ribeiro -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHJ/tmw3OYl0G0liQRAvpxAKCJ5I9DKU1abvGhSSAPf1JEzPBE9ACgj1oT SAEawNlu66ahlOBp02iq8YY= =diBw -----END PGP SIGNATURE----- |
|
From: Daniel R. <dr...@gm...> - 2007-10-31 01:53:26
|
-----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-----
|
|
From: Marcos D. <ma...@un...> - 2007-10-31 02:26:42
|
Daniel Ribeiro wrote: I finally understood your idea. It seems pretty good ! > 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. How does the HAL work ? If I already have two daemon running, with different configuration files each, but no device plugged and the first device gets plugged, will the HAL notice that the daemon is already loaded ? Or will it load a third daemon ? Even if no device gets loaded, how do we know the right daemon will talk to the device ? Marcos > > - -- > Daniel Ribeiro > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFHJ+59w3OYl0G0liQRAvLpAJ48CUnZhgqU5TGo1VohqYY53HeQeACggUjv > hNHKooyt0tKJqiFmC0GpWpg= > =x31O > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Easyb2k-devel mailing list > Eas...@li... > https://lists.sourceforge.net/lists/listinfo/easyb2k-devel > |
|
From: Marcos D. <ma...@un...> - 2007-10-31 10:29:56
|
> ATM we can assure that the control interface will match the respective > configuration based on the box serial number, but i dont know how to > assure that each VoIP application will open the correct PCM devices > matching the control interface on the same box. The Skype protocol allows us to choose the audio in and audio out for each call: https://developer.skype.com/Docs/ApiDoc/Voice_Streams Knowing what audio devices is associated with each Yealink device is also possible. (they are on the same USB hub ) By pinging, I meant checking if the VoIP app is alive. Nevertheless, even if no VoIP app is alive, but at least one device is plugged, then the daemon must be alive and every now and then ping the VoIP app, so that it can automatically work whenever it is open. By the way, if we want to have two different daemons talking to the same skype, they must report different names, or else Skype will go crazy. So there must be a configuration option for that. Now if we want to have two different Skypes on the same machine, I don't know how to do it, because at least XInternAtom(display, "_SKYPE_INSTANCE", 1); returns the first instance if finds. I launched one Skype normally and the other one through ssh -X user2@localhost. Does anybody has any better ideas ? Maybe DBUS works different. Marcos ps: Daniel, thanks. Now things make sence. |
|
From: Daniel R. <dr...@gm...> - 2007-10-31 13:36:30
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marcos Diez wrote: > Knowing what audio devices is associated with each Yealink device is > also possible. (they are on the same USB hub ) Great! This will make things much easier. > By pinging, I meant checking if the VoIP app is alive. > Nevertheless, even if no VoIP app is alive, but at least one device is > plugged, then the daemon must be alive and every now and then ping the > VoIP app, so that it can automatically work whenever it is open. Ok, so the ping should not be called on probe(), but each X seconds, and set an 'active' flag that enables the code. Good. > By the way, if we want to have two different daemons talking to the same > skype, they must report different names, or else Skype will go crazy. So > there must be a configuration option for that. Agreed. > Now if we want to have two different Skypes on the same machine, I don't > know how to do it, because at least XInternAtom(display, > "_SKYPE_INSTANCE", 1); returns the first instance if finds. > I launched one Skype normally and the other one through ssh -X > user2@localhost. Does anybody has any better ideas ? > Maybe DBUS works different. This needs a little more research, maybe asking on Skype forums? Anyway, if it is a Skype limitation they should fix it. :) > ps: Daniel, thanks. Now things make sence. You are welcome, lets wait for Thomas and Simon, and if they agree with the presented structure we may start the real fun :) - -- Daniel Ribeiro -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHKJM9w3OYl0G0liQRAtVnAJ0WkQo/eKy1JOl86K8/ATNXIonj1wCdF9wt aIq7ux77GsIPyVULseY7vLg= =+34G -----END PGP SIGNATURE----- |
|
From: Daniel R. <dr...@gm...> - 2007-10-31 04:48:16
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marcos Diez wrote: > How does the HAL work ? I never wrote an application using HAL, I will learn it during the initial development phase of our project :) http://www.ometer.com/hardware.html can give you some pointers on the motivation behind HAL. > If I already have two daemon running, with different configuration files > each, but no device plugged and the first device gets plugged, will the > HAL notice that the daemon is already loaded ? Or will it load a third > daemon ? Even if no device gets loaded, how do we know the right daemon > will talk to the device ? You will *not* have a daemon running *before* the device is plugged. And if you unplug the device, the daemon should exit. You dont need to know in advance which daemon will talk to the device, the daemon will select which .conf file (or .conf section) to use, based on the device's serial number. My idea is just fine when all that matters is the _control_ interface of the boxes, but we havent discussed how we will configure the VoIP applications to talk to the right sound device. As the sound codec chip on the telbox devices are handled by alsa in kernelspace this may be trouble for future development. ATM we can assure that the control interface will match the respective configuration based on the box serial number, but i dont know how to assure that each VoIP application will open the correct PCM devices matching the control interface on the same box. - -- Daniel Ribeiro -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHKBd5w3OYl0G0liQRAhHWAKCCnsYuPcauU/xkjn2Di4K6XSFA2gCfa0hp KSPCDyXBBSwtT+eSSE8nfQQ= =/Grm -----END PGP SIGNATURE----- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X