[Gpephone-devel] FW: Proposal of new phoneserver architecture

Nils Faerber nils.faerber at kernelconcepts.de
Wed Apr 11 11:02:35 CEST 2007


JIANG Dan RD-ILAB-PEK schrieb:
>> Hi,
Hi!

>> The following is our proposal about new phoneserver structure.
>>
>> Would you kindly have some time to look through it and give your
>> comments?

I don't have much except for a hint, did you have a look at the OpenMoko
gsmd? I think to some extend it also handles some of the aspects of
phoneserver and might be worth to have a look at.
Especially the handling of AT commands, buffering and application API
would be interesting to compare.

Since we should aim at working more closely together with OpenMoko to
avoid fragmentation it would be good to know where we stand and which
parts we might want to consider to offer to OpenMoko or reuse from them.

>> Thanks.
Cheers
  nils faerber


>> ======================================================================
>> ===============================================
>>
>>
>> Proposal for new structure of Phoneserver
>>
>> 1.	Structure
>> The whole phoneserver is made up of the following parts:
> 	Phoneserver manager
> 	Plugins: VOC, SMS, Phonebook, etc.
> 	AT builder & parser
> 
>> 2.	Functions of each model:
>>
>> 1)	Phone server manager 
>> Main program which monitors the IO channel, load and manage plugins,
>> AT builder & parser. 
>>
>> 2)	Plugins
>> One plugin corresponds to one service module, such as VOC module, SMS
>> module, phonebook module. The service modules are independent from
>> each other. Phoneserver loads the modules at initialization. 
>>
>> For example, the phonebook plugin deals with
>> *	The initialization of phonebook
>> *	Calling libabenabler APIs to deal with phonebook items.
>> *	Calling AT module to send out AT commands
>> *	etc. 
>>
>> 3.	AT Builder & parser
>> This part is used to send out AT commands to modem and analysis the
>> message back from modem. The AT commands and return messages are
>> different according to modem types. So This module is modem specific.
>> The module defines a set of universal interface for other modules to
>> use. Different files (.c, .h) are used for different modem. Different
>> compiling options are provided to fit for different modem.
>>
>> 4.	Some thinking
>> 1)	Why Plugins
>> 	*	Be easy for expansibility
>> 	*	Be easy for add/move modules. E.g., MMS could be easily
>> added to phoneserver as a plugin without recompilation.
>> 	*	Make phoneserve manager clean and simple. The current
>> phoneserver is large and complex. It needs support of libmsgenabler,
>> libabenabler. If libmsgenabler or libabenabler is modified, the whole
>> phoneserver has to be recompiled. In the new version, only plugins has
>> to be recompiled.  
>> 2)	How to make phoneserver suitable for many modems
>> 	*	The difference of diverse modems only lies in the AT
>> builder & parser part. 
>> 	*	Make the AT builder & parser part as small/simple as
>> possible.
>>
>>
>> 5.	Difficulties
>> How to define a set of interfaces in AT builder & parser module which
>> 			*	Easy for use
>> 			*	Easy for different manufactures to
>> modify when modem type changes
>> 			*	Fulfill as many functions as possible
>>
>>

-- 
kernel concepts GbR        Tel: +49-271-771091-12
Sieghuetter Hauptweg 48    Fax: +49-271-771091-19
D-57072 Siegen             Mob: +49-176-21024535
--

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: OpenPGP digital signature
Url : http://lists.linuxtogo.org/pipermail/gpephone-devel/attachments/20070411/ea8b1fa6/attachment.pgp 


More information about the Gpephone-devel mailing list