[Decibel] Qt4 client library for Tapioca

[Stefan Eilers]

Hi Santtu, hi tapicoa guys! :)

I think we should going to synchronize the discussion between kde,  
decibel and tapioka.
Currently, I see three combat areas we have to look at:

1. Dektop integration to KDE

a) Address information
The work towards KDE-4 is going to make very promising improvements  
which are related to our work. The Akondadi project  (http:// 
pim.kde.org/akonadi/) will provide a storage framework for PIM  
information. As we have to access these kind of information for  
connection purposes (getting the voip-number or the jabber address of  
a use) we should use them.

b) Protected information
We need to store information (like passwords) in a secure container.  
On KDE this is KWallet. I don't know whether this will be integrated  
into Akondadi and how we could access these information in a secure  
manner. To publish passwords unprotected via DBUS isn't a good idea,  
I fear.. ;)

c) Media Streaming and encoding/decoding.
Tapioca (as far as I understand) integrates the media stuff into the  
client, using a wrapper. We should think how we can add phonon to  
this idea. Especially if we have various desktop components instead  
one big client, it may be a good idea to separate both.

We should discuss a) and b) on kde-pim mailing list. As you (Santtu)  
has committed yourself for taking this part, it would be great if you  
could start to discuss it with them. Maybe we should coordinate a  
little bit some details , as we want to extend the tapioca framework  
itself to meet some requirements we have.

2. Tapioca Framework
Our part is to add a central service manager into the tapioca  
framework which has to activate desktop components on demand and to  
manage connection managers which is currently located in the client  
application. We will discuss this stuff with the tapioca guys on  
tapioca-voip-devel mailing list.

Last, but not least there is the new mailing list decibel at kde.org.  
This should replace it with the current decibel at basyskom.de which is  
too much related to our company. We should use it to discussions  
which should be kept within our three groups. The current thing to  
discussion on this list would be to have some announcements out and  
make public relation work. Technical discussions should be on related  
lists to integrate the KDE and Tapioca community.

Am 27.05.2006 um 20:43 schrieb Santtu Pajukanta:

> Hello,
>
> As per the IRC discussion with Tapioca developers (stored at
> http://telephonik.sourceforge.net/mediawiki/index.php/ 
> Talk:Tapioca#IRC_discussion_about_Tapioca),
> I'm starting hacking on a Qt client library for Tapioca.

Cool.. This would be very interesting. As written above, we have to  
address some important aspects to stop being to much client related.  
The question I have is: How to split a big monolithic application  
into small lightweight and exchangeable components and does the  
client API will handle it!?

> However, as it would
> seem that the Qt3 bindings are not in a usable state, the client  
> library will
> be Qt4 only.

Yes. Qt-bindings are work in progress. As the real work is on the Qt4  
branch, we have to look to Qt4, too. But this is OK, as we are  
looking for KDE4 anyway.
>
> I will follow the structure of the GLib client library where  
> convenient.
> Should no serious problems arise, I expect to have the API frozen  
> in a few
> weeks and a working version ready to be committed to Tapioca SVN by  
> the end
> of July.

Cool. I'm not sure whether you already thought about it. But I'm  
interested what you think about it:
If you read the Akonadi page, you will see that they will remove a  
lot of the usual desktop applications and remove them with views to  
the framework. For instance, instead of having a mail application,  
they will have a view to the mail database and an imap component  
which reads the mails from the server. This basic idea is equal to  
what we expect for tapioca in the future: Heavyweight Desktop  
applications are yesterday. The future are replaceable views (we call  
it components) which uses the framework to get specific tasks done.  
And if I don't like a special view (which might look like kmail) I  
will replace it with something which behaves like evolution.. But  
everything uses the same backend framework..

> Even though my focus is in writing a library I eventually can base
> Telephonik on, I hope the client library will also be usable in the  
> Decibel
> project.

I'm sure it will be a big step ahead!
We would be quite happy if we would be able integrate you into the  
main vision which appears around KDE: Do as much as reasonable into  
common and shared frameworks and use the desktop for user interaction  
purposes. The frameworks will be shared with --for instance-- Gnome  
or others. In our case, we expect that decibel will be interesting  
for mac-os and windows. Both don't have a modern real-time  
communication framework. But this needs a clear and clean separation  
between desktop and framework.

What do you think about it?

Mfg., Stefan Eilers
--  
Dr.-Ing. Stefan Eilers
Projekt Manager

basysKom GmbH
Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany
Tel: +49 6151 3969-962 | Fax: -736 | Mobile: +49 170 4213459 |  
Jabber: eilers at jabber.org
stefan.eilers at basyskom.de | www.basyskom.de



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 188 bytes
Desc: Signierter Teil der Nachricht
Url : http://mail.kde.org/pipermail/decibel/attachments/20060530/a1523d04/attachment.pgp