Q: What is "Real-Time Communication and Collaboration", what is KDE-Telepathy and what is Telepathy-KDE?
A: They are several names we are using for the same thing and that represent a set of applications, services and libraries that will bring Telepathy to the KDE desktop.
Q: What is libktelepathy and what is KTelepathy?
A: libktelepathy is the name of the main library in KDE-Telepathy, KTelepathy is the namespace for all methods and classes in this library
Q: Insert some Kopete questions here
Q: Does telepathy-kde4 replace and deprecated Decibel? It seems like decibel is completely gone now….
A: Yes, decibel is dead and gone. Forget about it.
Q: Will Telepathy-KDE result in yet another resource-hogging, hard-or-impossible-to-get-rid-of daemon like Akonadi?
A: No, it will not require as many resources as akonadi does and it will be possible to turn it off any time. Of course, in this case, you will lose all the collaboration features that it provides to KDE applications.
Please see the dedicated troubleshooting page here: http://community.kde.org/Real-Time_Communication_and_Collaboration/Troubleshooting
Q: Will each application that uses Telepathy-KDE keep it’s own contact list, or will all apps use a central contact list (e.g. one in KAdressbook or Kopete)?
A: You will have just one "contact list model" but you can have as many "views" on that contact list as you want. So each applications will share the contacts, but may have a different way to display them.
Q: Why I can't minimalize the contact list into tray?
A: KDE Telepathy is no monolithic IM app like Kopete/Pidgin but rather aims at Plasma Workspace integration using several independent components. Thus we don't provide minimize-to-tray functionality but other ways how to achieve the same.
Q: Why is KDE Telepathy not network aware.
A: The new central telepathy daemon (mission-control-5) is now network aware and will disconnect/connect accounts as appropriate. Putting it in the KDE code as well will cause a duplication of code and may have undesired side effects.
Q: Will it support video conferences (with jingle - to be compatible with google talk) and voice with SIP?
A: Yes, it already does.
Q: Will this technology also be used for supporting collaborative editing in KDE apps (e.g. KOffice)?
A: One of our goals is to offer to developers an easy to use framework that will allow this. Anyway developers of the single applications may choose to use it or not.
Q: Will there be a way to store your contacts to a flash drive for easy transfer between computers, or even using a contact list stored on a flash drive directly?
A: All metadata related to the contacts are stored on nepomuk. There was a GSOC project that will allow to backup and restore nepomuk database, so it will probably be possible as soon as this is possible. It won't be possible to store your contact list on a flash drive unless you configure nepomuk to store all your metadata there
Q: Is there a possibility of putting the chat interface directly in plasma instead of using a separate window, or an easy way for developers to embed a chat interface in their program for collaborative work?
A: We are planning to have a "chat widget" (or maybe a chat kpart) that you can embed in your program. Probably it will be possible to have a plasma widget that uses that widget.
With the modular nature of telepathy it is also possible to simply use a plasma widget instead of the supplied chat window, or even make it act as an "observer" showing a duplicate of everything going on the supplied chat window.
Q: When can we expect API stability?
Q: How will the contact-list be organized? Maybe through KAdressbook?
A: Contacts are stored in Nepomuk and are available to every application.
Q: Why are you using a git submodule.
A: We have library like code, but we can't offer API compatibility so at the time a git-submodule seemed like a good solution. In hindsight, maybe not.
Q: Send files in background to synchronize some metadata (ie: some small files, but the user doesn’t accept those explicitly)
A: When you send a file you can set mimetype and you can set a filter to your application so that the channel dispatcher will give to your application all file transfers with that specific mimetype. But some connection manager don't manage mimetype correctly.
Q: Is it possible to identify user just with IP+ssh key for instance, instead of requiring them to have an IM account
Q: Is it feasible to transfer huge files; can I resume a broken transfer?
Q: Can I do streaming, ie: audio or video streaming?
A: You can do streaming from your application, but you will need to duplicate some code from the call handler and use the GStreamer and Farsight libraries directly.
Q: Do you have python bindings for all of this?
A: Python bindings exist for telepathy-glib. You will have to use python-glib stuff though.
Q: and bonus question: how much of it is kde-specific and how much can be done with Qt only?
A: Well, you can do everything with telepathy-qt4 except the nepomuk integration part. Nepomuk is used for metacontacts, so if you don't use it and use telepathy-qt4 directly, you will lose metacontacts support.
Q: Telepathy seems to be a freedesktop.org specification. Does this mean that KDE and Gnome apps (with similar use cases) which both use Telepathy tubes will be able to interact smoothly? (Not only in theory, but also in practice?)
A: In theory yes, in practice also yes, as soon as they share the same protocol (for streamtubes) or the same dbus interface (for dbustubes).
Q: Does it work behind a firewall/router?
A: It does as soon as the port used for the connection to the im server is open.
Q: Are incoming connections restricted to trusted user? If not, what protective measures are implemented against spam, malicious impersonation, and similar attacks?
Q: secure connections