Tanguy Krotoff a écrit :
> Emmanuel BUU wrote:
>> This is the problem, I have the impression that Wengophone is composed
>> of too many software layers.
>
> And? do you really think this is a problem?
Yes, for maintenance, marginally for performance, for memory usage and
slickness of our beloved SIP phone. See below.
>> If we think about SIP, basically, to place
>> a call, we have to go through:
>>
>> Core Wengo phone -> CoIpManager -> SIP Wrapper -> phAPI -> exoSIp
>
> On the other hand the code inside WengoPhone' model and presentation
> (GUI) is way easier!
> CoIpManager will simplify a lot the code -> less bugs, easier to read,
> easier to port, easier to optimize, more consistent...
> I believe in high level components: this is history: look at Java, C#,
> Qt... compare to C, Pascal, MFC...
> (...)
>
> How can you be compatible with MSN, AIM, Jabber, SIP, IAX... without
> an abstraction? If Gaim is not good enough for Jabber for example, how
> can you replace the Jabber implementation for something else (Jiggle
> for instance) without changing the MSN, AIM... implementations that
> are using Gaim?
Tanguy, we definitly need an abstraction. The CoIpManager is a brilliant
idea. But the logical next step would be then to
* Select ONE SIP stack, ONE RTP stack
* A limited set of IM API with the minimum overlap
and implement CoIpManager plugins using those APIs / stack natively.
This would mean to scrap PhAPI for instance (sorry Vadim) and IMWrapper
and SIP Wrapper.
I am perfectly aware that this is a *huge work* but the direction shoud
be set, otherwise, WengoPhone code will stack abstraction layers after
absttraction layers and become very difficult to maintain. It will be
like layers of sand or mud in rivers and after a couple of million
years, people will dig into this to find dino bones :).
> glib because of Gaim
> Qt for the GUI
> Boost for the model so we are independant from Qt for this part Boost
> has been already discussed here:
>
> glib issue can be solved: one can take Gaim modules (MSN, AIM,
> Jabber...) without the abstraction model (...) But I don't really
> think this is priority.
I guess code maintainability is not never issue until the maintenance
costs are too high.
> For Boost and Qt this won't be solved: this is done on purpose and
> developers are pretty happy with it. Yes we know that for external
> developers installing/compiling Boost + Qt4.1 is a pain in the ass.
Well, boost has been chosen. Full stop. We know that Qt framework and
boost overlap but you're right, this has been discussed and there is no
point in going back.
It should however be possible to compile separately the model of OW
without any QT dependency and then compile a Qt presentation WITHOUT
BOOST compilation dependency then link the whole thing together.
I am aware that presentation / business logic are already separated but
this clearer seperation would make easier for service provider to embed
your product without having to use boost and be constrainted by your
choices. For instance, create a browser plugin and implement the whole
GUI as HTML and Javascript as I dream to do one day ...
It should be possible to also look toward code simplicity and use less
hundreds of classes and templates and ... Yes, regarding object oriented
programming, I am agnostic and I have seen to big projects die because
of design pattern overuse.
>> * Video codecs : I have read aboud some issue regarding the SDP used
>> for H.263 that prevented interoperation with external devices.
>> Also what about the H.264 + plugin effort developed by Mr.
>> Schneider ?
>
> Jerome Wagner is in holidays that's why ;)
Great ! Matthias work is just brilliant. H.264 *should be a priority*
for the future.
Please, your work is great. I am just an old style grumphy programmer
that values simplicity & flexibility of code over structures. I don't
mean to criticize the project as a whole.
Emmanuel
_______________________________________________
Wengophone-devel mailing list
[email protected]
http://dev.openwengo.com/mailman/listinfo/wengophone-devel
