Slashdot Mirror

My colleague likes your idea but proposes you also make an XMPP extension to enhance the instant messaging experience. The Jabber client can then choose to support this extension in the form of a mood processor. Instead of marking text and adding e.g. "bold" as a modifier, you can mark text and mark it as "sad", "indifferent", "cough*word*cough", "sexy", and so on.

I'm not a standards guy neither a game developer, but I'd propose something based on other standards, like XMPP for messaging, connectivity, chat and X3D for virtual world 3D models.

There is Jabber/XMPP for that.

http://en.wikipedia.org/wiki/Extensible_Messaging_ and_Presence_Protocol
http://www.xmpp.org/
http://www.jabber.org/

Indeed. Though, XMPP (commonly known as Jabber) stands to be able to solve these problems. I suggest you try getting involved with that project. Check out some of their specifications: http://www.xmpp.org/extensions/

Examples include: XML-RPC, SOAP, geolocation, vcards, nested sub-groups. Metacontacts: these are the sort of things that Pidgin and Adium are so great at doing, where you combine multiple accounts of the same people into one. Officially supported user mood, activity, tune, avatars, gaming, browsing, encryption, message formatting with XHTML rather than the sort of hack applications for other protocols such as MSN Plus-style applications.

Officially, things like transports work fine to combine your IRC, MSN, AIM, etc. all into one at the server side. It's distributed and inter operable, and the server admin can make his/her own rules for corporation use and such, like no talking outside the business unless you're on breaks. Officially, the file transfer spec has stuff for breaking through firewalls using WebDAV, or if not possible, fallback on sending it through the server (obviously would be throttled though). It supports transfer resuming too. Even things like encrypted offline messaging is supported.

Voice and video works with RTP... using codecs such as Speex for voice and Theora, x264 for video, again using things like STUN to set up the session. SVG whiteboards are in the works too.

The protocol is fabulous, and clients are busy implementing it all. Don't think that Pidgin's jabber performance is representitive of the protocol, it's very out of date and crappy. I think work is going into this though. The hard part is GUI-ifying the features of XMPP, especially when clients such as Jabber insist of doing it with perfect integration to the systems.

One of the primary reasons it doesn't support VoIP is that the Jingle specification for voice and video chat over Jabber/XMPP hasn't completely settled yet. It is currently in "experimental" state, but it is expected to rise to "draft" state very soon http://blog.xmpp.org/ . Then Google's libjingle will be updated according to this standard, and lots of programs (Pidgin, Kopete, Psi, ...) will have VoIP support through open free standards.

Hey, right you are:
http://www.xmpp.org/extensions/inbox/jingle-ft.htm l
Would be great to see this happen

The old file transfer:
http://www.xmpp.org/extensions/xep-0096.html

Hey, right you are:
http://www.xmpp.org/extensions/inbox/jingle-ft.htm l
Would be great to see this happen

The old file transfer:
http://www.xmpp.org/extensions/xep-0096.html

But AIM and MSN transfer files. Jabber doesn't.

See RFC 3290 for the IETF RFC spec of XMPP and XMPP.org for the home of the Extensible Messaging and Presence Protocol.

Your call for collaboration does not help the business models of AOL (AIM), Microsoft (Windows Live! Messenger) or Apple (iChat) because it cedes their control and might lose users from their platform. The big names aren't interested in it, but we-the-little-people can run our own network of OpenID enabled Jabber chatting.

think in TFA it is meant that there is no VOIP Google Talk support

Once again, that isn't support for google talk. Google talk is simply a Jabber client written by google. When someone talks about google talk's VoIP functionality then that person is talking about Jingle, which is a Jabber standard element.

So please don't get confused about this one. Google talk is simply the client (like Psi, Gaim, Kopete, etc) while the protocol itself is Jabber.

...and they picked jabber for a reason. I think Google puts the philosophy behind Jabber best in their Google Talk FAQ. Long story short, if you all used Jabber, this wouldn't ever have been an issue to begin with...

<anal>Not all IM is closed</anal>

How about this standard?

I guess the first thing we need is some kind of gateway between XMPP and SIMPLE...

Suppose it would be really great to have a single generic protocol for instant messaging, but if there will be no dictator like Microsoft behind it. This system should be distributed and with opened specifications (as Jabber/XMPP). Clients for it's network should be exist for various platforms, not only for win32 and mac. The ability for running own server is also important.

That's 46% of Jabber.com, a commercial implementation. "Jabber" is actually XMPP, the Extensible Messaging and Presence Protocol, an IETF standard.

Baricom: What you're looking for is the "cloud" interface defined at: http://blogs.law.harvard.edu/tech/soapMeetsRss
The documentation there is, I think, about as good as you'll find. While it says that it can be implemented in either XML-RPC or SOAP, I am aware only of XML-RPC implementations.

The cloud provides a means for blogs to notify subscribers of updates and should eliminate the need for polling -- except that the subscriptions must be renewed at least every 25 hours. Of course, this cloud stuff isn't terribly useful in most cases since it relies on the blog server being able to send an HTTP message to a remote client (subscriber). In most cases, those messages would be blocked by firewalls. This is, of course, why the "Atom over XMPP" stuff makes sense. It relies on a connection established from the client to the server -- in the same manner as is done with instant messaging clients. Thus, there are many fewer issues with firewalls.

Of course, having lots of session open between a client program and all of the various blogs it reads probably doesn't make much sense. Neither does it make sense for every blog to maintain a list of all of its "cloud" readers and go to the work of sending them all messages whenever the blog is updated. Thus, the most sensible way to do this push business is to have the individual blogs publish to a common network of aggregating servers and then have clients establish connections to the common service. Overall bandwidth consumption is thus reduced to the absolute minimum. That's what we're building at PubSub.com.

bob wyman

While there are some great ideas in RSS, one of the worst is polling. As discussed in Burton's post, polling results in a ridiculous waste of bandwidth. A Push approach, like the one defined in "Atom over XMPP" would result in a massively more efficient distribution system like the one that we implement in the PubSub Sidebars. But, if you insist on polling, then the best efficiency can be had by combining Gzip with the A-IM or RFC3229+feed as described on my blog. Using RFC3229+feed, your server would only serve up "unread" entries not everything in your feed. Please read and implement: http://bobwyman.pubsub.com/main/2004/09/implementa tions.html

bob wyman
CTO, PubSub.com

Bzzzztt....

Sorry, thank you for playing.

You only need huge great servers if you think like AOL and wish to control everything. If you use protocols like XMPP (e.g. like Jabber) then you can have decentralised small servers very similar to how email works. That way you have much greater scalability and openess.

There is an IETF standard, XMPP. And as it is rather extensible, I'm sure it can do whatever AOL thinks they want to make their protocol do.

The problem is, other than Jabber, nobody (AFAIK) has implemented it. Ever so slowly, but ever so surely, it is sinking in that there is no longer any point to having your own "gated community" when everybody just has an account on all of the services and uses a multi-network IM client that still doesn't show your commercials.

If AOL chooses to release something other than XMPP that tries to solve the same problems, only in AOL's way, developers should shun the new protocol and insist that AOL implement the standard instead of creating their own. Things that can connect to XMPP exist today. Nothing today exists that can use Tomorrow's Yet Another Proprietary AOL Protocol.

Until this occurs, it still won't have fully sunk in. IM is commoditizing. Actually, it's already a commodity, and only by artificially locking up the market have the large networks made it even this far, and that is an unnatural, unstable accomplishment that will inevitably break down, not something to build a business on.

Massive polling for updates leads to scalability problems? Big surprise! We need to learn that HTTP is not always the best technology for the job. Just-in-time content delivery requires a different set of tools. There's already an Internet-Draft for sending Atom feeds over XMPP (a.k.a. Jabber), and the same "publish-subscribe" technology could be used for RSS (or a smart service could translate to Atom so your client doesn't need to parse all those RSS formats). Check out PubSub.com for a real-life implementation of the basic concept (they track 3+ million feeds and notify you when a feed you're interested in has changed, and even do handy keyword-based monitoring). And one added benefit of using the XMPP pubsub extension is that these are all open protocols with many open-source implementations. In this problem-space at least, HTTP is so second-millennium!

http://xmpp.org/drafts/draft-saintandre-atompub-no tify-01.html

What about XMPP?

For those unaware, iChat has always used the Jabber protocols for its local (Rendezvous-initiated) messaging. This just dusts off and reveals full-fledged support for Jabber.

Why Jabber? Because Jabber is a completely open IM standard. The IETF has accepted the core Jabber protocols and has standardized them as XMPP, an open IM protocol.

I have a few domain for free
WUSB.Com is Free
Think of it as Open Source for Domains

We have given several FREE domains to great groups:
Vancouver Oracle Users Group
Greylisting (anti-Spam)
Jabber Software
Xaml .Net
Open Wiki

Please mod this UP.
This is an honest offer to support the Open community