From: Stefan E. <ste...@ba...> - 2006-05-30 09:56:35
|
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 de...@kd.... This should replace it with the current de...@ba... 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: ei...@ja... ste...@ba... | www.basyskom.de |