Gof's weblog - Commentaires

Instant messaging integration into the Desktop - -=RO=-tian

-=RO=-tian — 2006-07-26T12:34:09+02:00

I must say i dislike kopette so i preffer gaim to be used instead.

Instant messaging integration into the Desktop - sd

sd — 2006-06-17T17:22:03+02:00

@Matt Rogers: "You're fooling yourself if you believe that Jabber will be the only surviving protocol. The others will continue to survive and be in use."

I think Gof is right. Other popular communication networks already died in the past: telex, post doves, telegraph, email, and so forth. Regarding email, there is a *must-read* blog article: nugget.livejournal.com/97...

"We'll need to support them natively. The jabber idea is neat, but the telepathy idea seems like the way to go. We could then dump some of our crappy implementations or work with the other on combining our efforts so that everybody who uses telepathy benefits"

I don't agree, I think it would be much better to just drop support for proprietary protocols as much as possible. I will explain later, but first some quote:

"The short-term approach to interoperability in the Jabber community has been to deploy gateways that reverse-engineer the closed protocols used by AIM, ICQ, MSN Messenger, and Yahoo Messenger. There are many such gateways on the Jabber/XMPP network, but this is not the right way to bring about interoperability for the long term (it's as if you had needed gateways back in 1993 to send email to your friends using CompuServe or Prodigy, whereas what was really needed was a single protocol for email, which emerged in the form of SMTP). The long-term approach has been to work toward ever-wider adoption of Jabber technologies so that the consumer IM services will want to open up true server-to-server communications with the Jabber network using the core Jabber/XMPP protocols as standardized last year in RFC 3920 and RFC 3921 by the Internet Engineering Task Force (the main standards body for the Internet). At that point XMPP will become the lingua franca for IM, just as SMTP is the lingua franca for email. I think we are seeing signs that this strategy is beginning to pay off." (from www.jabber.org/journal/20...

My opinion can be found here:
mail.jabber.org/pipermail...

There are the most important lines:
"I do *not* recommend any multi-protocol client; the
developers resources should be focussed on Jabber/XMPP support only, and not on reverse engineering some bad protocols. Alternative clients to proprietary systems are just bad, as they give people using that network a choice; it is much better if only the Jabber network has choice in good Jabber-only clients."

So, why I think multi-protocol clients contain much competitive disadvantages:

You make your software more complex than mono-protocol clients like Jabber-only clients or MSN Messenger.
You spill time on reverse engineering which you better can use to make your client more stable or add nice features to make your client better than e.g. Yahoo! Messenger.
You create choice for users of proprietary networks. It is much better if the only choice they have is to use a Jabber transport, as this means that they need to have a Jabber account. And all users that used their choice can use Jabber to contact each other instead of the propreitary protocols.
Your client will contain more bugs and bloat.
You need to do urgent releases when a proprietary protocol owner changes his network as your client can't connect anymore to that network.

Yes, I would be very happy when GAIM and Kopete drop support for all their proprietary protocols B-)

And if you really want to reverse engineer, create/improve transports: www.modevia.com/pipermail...

Instant messaging integration into the Desktop - sander

sander — 2006-06-17T16:24:08+02:00

"There is none Jabber-to-Jabber gateway yet"
This is only a matter of time; there already exists Jabberlang, an Erlang library to make Jabber clients. It only needs to be integrated into ejabberd ;-)

Instant messaging integration into the Desktop - idoric

idoric — 2006-06-17T11:47:53+02:00

You said "There is none Jabber-to-Jabber gateway yet" but :
blog.mabber.com/eintrag.p...

Instant messaging integration into the Desktop - Snark

Snark — 2006-06-16T19:32:09+02:00

Ekiga is a very good open source VoIP client, able to do both H.323 and SIP communication.

It also has a DBUS component to control some of it.

Instant messaging integration into the Desktop - Rob Taylor

Rob Taylor — 2006-06-13T01:54:04+02:00

I ahve to say that there are a couple of misconceptions of Telepathy in this article, so I best correct them ;)

1) the diagram is rather wrong - there is no 'Mission Control' that mediates all communication. This was a misconception introduced by the guys from BaSysCom. All communication is direct from client (ui, addressbook sync, videophone, etc) to the relevent connection manager.
The role of a "mission control" e.g. such as exists on the new 770 software is simply to act as the 'ui policy' - "I have an incoming media channel, what should be laucnched to handle it?" etc.
2) Connection managers certainly aren't daemons in the standard sense of the word, they are simply dbus services.
The benefit of this, and the whole reason for this structure is to allow disparate applications to communicate with the 'connection' - eg your word processor can do collaborative document editing without your messageing client being loaded.

Thanks,
Rob Taylor (Telepathy Project)

Instant messaging integration into the Desktop - Vlad

Vlad — 2006-06-12T17:21:34+02:00

A good Voice over IP (VoIP) client is Open Wengo:

OpenWengo.org

It has several advantages:

* Open Wengo has strong developer and commercial support from France's leading VoIP provider
* Open Wengo is 100% Free & Open Source software (GPL-licensed)
* The backend library is clearly separate from the GUI frontend, making it easy to incorporate in applications.
* The existing GUI frontend is Qt-based and crossplatform (Linux, Windows, and Mac OS X)

trackback - Instant messaging integration into the Desktop - Attracted by virtual constructs

Attracted by virtual constructs — 2006-06-11T17:54:17+02:00

It’s about Contacts

Do you know finger, talk, write, who, etc.? You could if you had gotten in contact with unixoid computing systems. With the concept of client and server, multi users, sharing resources, connected systems, and collaboration were part of the system. The ...

Instant messaging integration into the Desktop - Chani

Chani — 2006-06-09T17:09:50+02:00

what liquidat said. :) it is pretty silly that I'm doing this. at least the guy from last year documented his work, which made my job much easier. I spend most of my time trying to figure out the "kopete way" to implement things, or what's already been done somewhere else in kopete and could be combined if it was done more cleanly...

oh, and we probably have to consider the case of the rare people that don't want an all-in-one kde solution, and not make kopete too annoying for them - but I'm not one of them :)
I think the jabber thing is a great idea, too - anything that makes jabber cooler than other IMs is good ;)

Instant messaging integration into the Desktop - Matt Rogers

Matt Rogers — 2006-06-09T16:54:29+02:00

Gof: You're fooling yourself if you believe that Jabber will be the only surviving protocol. The others will continue to survive and be in use. We'll need to support them natively. The jabber idea is neat, but the telepathy idea seems like the way to go. We could then dump some of our crappy implementations or work with the other on combining our efforts so that everybody who uses telepathy benefits

Mario: we've heard about it, and let's just say that there are issues with it.

Instant messaging integration into the Desktop - liquidat

liquidat — 2006-06-09T15:32:35+02:00

I'm missing information about decibel as well as information about the tapioca framework:
tapioca-voip.sourceforge....
It is the preferred backend for decibel.

About the comparison:
I think the protocol implementation is a point which should be more respected: sure, kopete already implements basic support for all protocolls, but some specific features are better implemented by other clients but not by kopete and the other way around - the best way would be to bundle as much effort as possible, or, at least to not double too much effort.
This could be done through such a central framework which is shared by the most clients.

At least at the moment it is a joke that for example one Summer of Code project is doing the same for kopete what another project done last year for gaim (oscar file transfer) - and at the same time there are several clients which try to implement voip-jingle, and everyone starts at the beginning.

It just looks too much like every step is done again and again for each client which could be avoided with a more central attempt where all protocol experts are working together.

Instant messaging integration into the Desktop - Bille

Bille — 2006-06-09T14:02:38+02:00

Akonadi is the PIM data store for kmail, kabc, korganizer. We could store metacontacts there, and also log conversations.

Instant messaging integration into the Desktop - Mario

Mario — 2006-06-09T14:02:15+02:00

Do you know Decibel (decibel.kde.org)?

Instant messaging integration into the Desktop - Gof

Gof — 2006-06-09T13:53:02+02:00

If I understand correctly, akonadi is the replacement of KABC in KDE4. So yes, this is the good candidate to manage contact identifier in the KIMProxy model.

Instant messaging integration into the Desktop - superstoned

superstoned — 2006-06-09T13:35:59+02:00

What is the possible role of akonadi here? couldn't it be the layer in which all info can be shared?

Instant messaging integration into the Desktop - Duncan

Duncan — 2006-06-09T12:50:57+02:00

Perhaps the solution is a very small, lightweight jabber daemon that acts solely as a message router for the local applications. Kopete can handle accounts as normal, but report presences to the internal daemon. If the daemon isn't running, don't panic, but tell the user that it's not working properly, and that the integrated features won't work until it's back on-line. Offer to bring it back up if possible. If the daemon can be implemented as a state saver that runs at the end of a pipe, and doesn't need to be a permanently running 'thing', then you might even get the best of both worlds.