Let's have this discussion on the mailing-list. It's better
--
Tanguy Krotoff <[EMAIL PROTECTED]>
http://openwengo.org
--- Begin Message ---
P. Durante wrote:
I want to integrate it into
qtwengophone itself (like gaim-remote or the skype api already do)
which brings me to the first problem: by design, the presentation
factory is a singleton, which means we can't have two presentation
instances running in the same app, one solution might be to 'dive
deeper' and make the D-Bus objects boost::bind() to events coming
directly from the model layer, is this acceptable? do you have a
cleaner solution?
This is not a good solution: the control layer has 2 goals:
- provide a nice API
- handle the thread safe problem
I think the best is to work on the factory and try to find a pattern to
have several presentation layers at the same time.
Here the code I'm thinking about:
class PFactory : Interface {
virtual PPhoneCall * createPPhoneCall() = 0
}
A new class MultiPFactory:
class MultiPFactory : public PFactory {
addPFactory(PFactory * pFactory) {
_list += pFactory
}
removePFactory(PFactory * pFactory) {
_list -= pFactory
}
List<PPhoneCall *> createPPhoneCallList() {
foreach i in _list {
pPhoneCallList += _list[i]->createPPhoneCall()
}
return pPhoneCallList
}
}
class PPhoneCall : Interface {
virtual phoneCallStateChangedEvent(state) = 0
}
class CPhoneCall {
CPhoneCall() {
_pPhoneCallList = MultiPFactory::createPPhoneCallList()
}
phoneCallChangedEventHandlerThreadSafe(state) {
foreach i in _pPhoneCallList {
_pPhoneCallList[i]->phoneCallStateChangedEvent(state)
}
}
}
MultiPFactory permits to have as many PFactory as we want. One can
imagine that MultiPFactory uses SharedLibLoader class to instanciates
PFactories at runtime via DLL. Thus you have a generic plugin
architecture for WengoPhone.
(
Now the problem is how to make plugins communicate with each others?
Maybe PFactory has a contructor (or a setter) like this one:
PFactory::PFactory(List<PFactory *>) + PFactory::getPluginName()
Thus PFactory should be renamed PPlugin
)
About the ColpManager component (which sounds like a very good idea),
how and how much are the internals going to change with this new
design? (I'm asking this in order not to break a lot of things when
I'll have to merge my code in mainline).
It will take time to get a working CoIpManager and to integrate it:
everything about PhoneCall, PhoneLine, ConferenceCall has to be rewritten.
A good 4 months will probably be needed to get CoIpManager working + to
rewrite model/control/presentation/qtpresentation.
So you don't have to really worry about this right now.
The last issue I'm having (sorry for the long message) regards
threads, as I currently see it, at any time there are at least three
threads running: the model thread ( spawned by WengoPhone->start() ),
the primary thread ( used for presentation and running
PFactory->exec() ), and probably another running the IMWrapper (with
its own glib mainloop), using postEvent() to pass events from the
first to the second one, is this right? ( I wasted quite a bit of time
because the former xpcom library didn't implement events and I was
pulling my hair to understand why the presentation callbacks where
never invoked :-( ) if so, what's the rule-of-thumb you have to
determine in which thread a particular method has to be executed? I'm
thinking about running dbus in its own thread as well, is this
acceptable?
Thread safety is the purpose of the control layer, unfortunatly I never
had time to finish this so there is a lot of PostEvent() inside the Qt
presentation layer: they will be all moved to the control layer over time.
Here the 'ideal' design:
XPresentation -> call Control -> call Model using a WengoPhone::postEvent()
XPresentation receives an event via the interface Presentation <-
control sends an event using PFactory::postEvent() <- model sends an event
with XPresentation = QtPresentation, XPCOMPresentation...
A good example with source code is somethimes better ;)
class QtPhoneCall {
makeCall(phoneNumber) {
_cPhoneCall.makeCall(phoneNumber)
}
}
class CPhoneCall {
makeCall(phoneNumber) {
WengoPhone::postEvent(makeCallThreadSafe(), phoneNumber)
}
makeCallThreadSafe(phoneNumber) {
_phoneCall.makeCall(phoneNumber)
}
}
and when QtPhoneCall reveices an event via the interface PPhoneCall:
class PhoneCall {
setState(state) {
phoneCallChangedEvent(state)
}
}
class CPhoneCall {
phoneCallChangedEventHandler(state) {
PFactory::postEvent(phoneCallChangedEventHandlerThreadSafe(), state)
}
phoneCallChangedEventHandlerThreadSafe(state) {
_pPhoneCall->phoneCallStateChangedEvent(state)
}
}
class PPhoneCall : Interface {
virtual phoneCallStateChangedEvent(state) = 0
}
class QtPhoneCall : public PPhoneCall {
virtual phoneCallStateChangedEvent(state) {
QLabel->setText(state)
}
}
Ideally if the control layer was fine and finished to be implemented,
control layer + Presentation interfaces are the complete API for the
WengoPhone. In such a case you don't need to bother about thread safety:
model is thread safe since the control layer take care of this part and
your 'presentation' layer for DBus is thread safe aswell since each time
control calls your 'presentation' it does a PFactory::postEvent(). You
just need to implement your own DBusFactory::postEvent()
In practice we never had the opportunity to fully work on the control
layer and to handle the thread safe problem completely.
How I see it now:
Create a DBusFactory (officiel name is D-Bus see
http://www.freedesktop.org/wiki/Software/dbus )
Imagine that there is already a MultiPFactory, anyway it will change
nothing to your code if there is one or not.
Implement PPhoneCall and all its friends
Each time you need to, add a postEvent() inside your code while thinking
that one day or another they will be removed.
Sorry for the late answer.
If you have any questions feel free (I bet you have right? ;)
Regards,
--
Tanguy Krotoff <[EMAIL PROTECTED]>
http://openwengo.org
--- End Message ---
_______________________________________________
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel
