Hi Vadim, The main goals of refactoring phapi are:
1. To make it even easier to use. 2. To make it more extendable (Easier to add new functionalities with a new Plugin system. Able to handle all kind of communication sessions (File transfer, VNC, etc.), not only voice and video. Please see more comments inline. > 1) Simplicty to design a softphone using the api > Methods to achieve: > - Only one include file > - Very strightforward API with 8 entry points (well at least > initially) The new APIs are designed to make it even easier to design a softphone. For example, the old phapi required developer to fill the phcfg global variable with data before calling phinit. This variable contained many fields that are not easy to guess. In the new API, we will make this phcfg create setter and getter functions to modify the values in a much more clearer way, with error checking, etc. > > 2) Portability > Methods to achieve: > - Using only C ant not C++ > - Separation of HW and OS dependent stuff > > 3) Possibility to run in embedded environement > Methods to achieve: > - choice of oSip eXosip and oRTP -- which gives very low > memeory footprint around 400k The portability of the code will not be sacrificed. > > I believe that i've more or less achieved these goals I do agree with you. > Of course the with time phApi evolved and in some way drifted from > these intial goals > and additional goals appeared and at least partially reached with the > help of Wengo team and community: > 4) video support: > Methods to achive > developement of libwebcam, pixertool and useage of ffmpeg > > 5) Extensibility with respect to codecs: > Methods to achieve: > developpement of codec plugin framwork Agree. > I see following additional goals for phApi > > 5) Support for SRTP and ZRTP > Methods to achieve: > rewamp TUNNEL_XXX set of macros into a notion of stackable > transports for oRTP > so we'll be able to stack one transport on another We have implemented srtp with phapi. We had to do that by patching eXosip and oRtp. A goal of the refactoring process is to be able to implement this kind of feature in the future just by adding a plugin to phAPI. We can discuss more about this. > 6) Extensibility with respect to audio/video devices > Methods to achieve: > developpement of audio/video device plugin framework > > > 7) Simplifying conference API and allowing more than 3 memebers in > the conf call > > > > 8) Removing dependencies on C++ when possible: > Methods to achieve: > redesigning libwebcam in C Effectively, these are also what we would like to have after the refactoring process. Best regards, Minh _______________________________________________ Wengophone-devel mailing list [email protected] http://dev.openwengo.com/mailman/listinfo/wengophone-devel
