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/branches/wifo-refactoring/phapi/phapi.h
http://dev.openwengo.com/trac/openwengo/trac.cgi/browser/wengophone-ng/branches/wifo-refactoring/phapi/phevents.h
http://dev.openwengo.com/trac/openwengo/trac.cgi/browser/wengophone-ng/branches/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
