OK, I've looked a litte at the code-structure of both repositories, thats what I've found:
- Verona is at http://www.mbdsys.com/opensource/verona the hg repo at http://www.mbdsys.com/repo/verona On Fri, Nov 14, 2008 at 06:56:29PM +0100, Vadim Lebedev wrote: > Couple of years ago > > Wengophone-2.0/wifo == Verona > > Since than Wengo added owpl layer and sfp-plugins and generic transport > layer OK I can see this, in more detail: Verona qutecom-2.2 --------------------------------------- eXosip wifo/eXosip libosip2 wifo/libosip2 ortp wifo/ortp phapi wifo/phapi miniua wifo/phapi/test/miniua libs/curl libs/3rdparty/curl libs/ffmpeg libs/3rdparty/ffmpeg libs/openssl libs/3rdparty/openssl libs/pixertool libs/pixertool libs/portaudio libs/3rdparty/portaudio libs/timer libs/timer libs/util/cutil < libs/owutil/cutil libs/util/memorydump libs/owutil/memorydump libs/webcam libs/webcam (the < means that the verona version is only a small subset for the cutils) Not in qutecom but in Verona: httptunnel - phcpp - Not in Verona but in Qutecom: - wifo/netlib - wifo/owbase - wifo/owsl - wifo/phapi-util - wifo/srtp - wifo/sVoIP - wifo/wifo-plugins I haven't yet looked into the various versions of external libs. Are these generally newer in qutecom-2.2 or in verona? > And we at simply stabilized the Verona and made some small enchancements > (like e-tag handling) Do you thing that the stabilisation warrants porting of verona (back) to qutecom so that we may fix some of the mentioned problems: > >We're seeing all sorts of hard-to-reproduce problems: > >- instability on network loss > > http://tracker.kvats.net/kvats/issue101 > > http://tracker.kvats.net/kvats/issue83 > > and probably also > > http://tracker.kvats.net/kvats/issue116 > >- instability when using conferences (both audio and video): > > http://tracker.kvats.net/kvats/issue114 > >- very seldom problems when putting a call on hold: > > http://tracker.kvats.net/kvats/issue82 > >- Presence: Sometimes the presence infrastructure (we're using p2p > > presence) sends weird presence information with some default values. > > We've worked around this by sending presence info via an > > application-timer > >- Other hard-to-reproduce problems > > http://tracker.kvats.net/kvats/issue94 The major roadblock is probably that verona doesn't use boost and qutecom internally still uses boost for communication of the various threads, http://www.mbdsys.com/opensource/verona/ says: "This toolkit is basicaly the same as used by OpenWengo project but modified to avoid dependence on Boost libraries." This means for porting to qutecom we should get rid of boost -- at least for communication with the sip-stack. What *does* Verona use for communication with the application? Qt libs? I think it's a *good* idea to get rid of boost but I also think it's major effort, we would need to re-think the communication. Currently bugs are lurking in the way qutecom schedules callbacks to objects which may no longer exist when the callback arrives, I've discussed an instance of this with Laurent @ Krems. Maybe a related question: What do you think about a D-Bus interface to Verona similar to http://telepathy.freedesktop.org/spec.html that would de-couple the sip-stack from the application. Ralf -- Dr. Ralf Schlatterbeck Tel: +43/2243/26465-16 Open Source Consulting Fax: +43/2243/26465-23 Reichergasse 131 www: http://www.runtux.com A-3411 Weidling email: [EMAIL PROTECTED] osAlliance member email: [EMAIL PROTECTED] _______________________________________________ QuteCom-dev mailing list [email protected] http://lists.qutecom.org/mailman/listinfo/qutecom-dev
