Re: [Easyb2k-devel] Application Structure

[Marcos <ma...@un...>]

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
>