Hello Vadim, It's good if you can dig into this discussion with Minh. (I had hoped you 2 could take more time on it in the last weeks since I asked you two to look at this refactoring effort).
This refactoring effort has only one goal at this stage : - improve readability of phapi.h - improve documentation - improve code split between functions when necessary to avoid files with too many lines - improve enums and function returns in order to have a clearer convention on the subject - do a prototype cleanup to build on what we have learnt so far regarding communication over IP at the SIP level. It is coherent with the other objectives we have in common for phapi and must be done in order to lower the difficulty of entry and the learning curve into phapi that everyone has to face. Linked with that is a doxygen nightly generation chain that I am setting up in order to clarify these entry points. I hope you can participate in Minh's effort on the subjet and give your thoughtful expertise. Please do not hesitate to contact him. Thank you, Jerome -----Message d'origine----- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Vadim Lebedev Envoyé : mardi 17 octobre 2006 11:50 À : [email protected] Objet : Re: [Wengophone-devel] branches and wifo-refactoring Jérôme WAGNER wrote: > Hello, > > > > As a side project that begun some weeks ago, I asked Minh to review > phapi.h and see how we could leverage our 2 year anniversary of SIP > problems and revamp it in order to make a more clear, more easy to > understand and less prone to error interface. > > > > Some of you may have followed this work in the wifo-refactoring branch. > > > > Please look at some entry points and comment : > > > > New Ones: > > http://dev.openwengo.com/trac/openwengo/trac.cgi/browser/wengophone-ng/branc hes/wifo-refactoring/phapi/phapi.h > > http://dev.openwengo.com/trac/openwengo/trac.cgi/browser/wengophone-ng/branc hes/wifo-refactoring/phapi/phevents.h > > http://dev.openwengo.com/trac/openwengo/trac.cgi/browser/wengophone-ng/branc hes/wifo-refactoring/phapi/phvline.h > > > > Old One: > > http://dev.openwengo.com/trac/openwengo/trac.cgi/browser/wengophone-ng/trunk /wifo/phapi/phapi.h > > > > Minh will try and summarize your comments to take into account your > needs in this revamping process. > > Thank you, > > Jérôme > > > > Ps1: Just to be more precise : this does not put on hold the necessity > we have to clarify the repository layout and packaging of wengophone > 2.0 on which we will have to work in the next days. It is a crucial > refactoring that we need to do before it is too late and that will > impact in the mid-term current phapi users so I want to give it > sufficient publicity so that everyone can be involved. > > > > Ps2: A porting guide will be written to help users understand the new > API and help them upgrade their application. > > > I wonder if somebody would bother to define clearly the goals of refactoring effort. And then we can discuss the validity of goals and various approaches with respect to these goals. For example: when I designed phapi I had 3 main goals: 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) 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 I believe that i've more or less achieved these goals 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 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 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 So i repeat my question: what are the goals of refactoring effort? Thanks Vadim >------------------------------------------------------------------------ > >_______________________________________________ >Wengophone-devel mailing list >[email protected] >http://dev.openwengo.com/mailman/listinfo/wengophone-devel > _______________________________________________ Wengophone-devel mailing list [email protected] http://dev.openwengo.com/mailman/listinfo/wengophone-devel _______________________________________________ Wengophone-devel mailing list [email protected] http://dev.openwengo.com/mailman/listinfo/wengophone-devel
