Search posterous

Search all posts and users. Type a name, type a favorite song title, whatever! See what comes up.
  

More posterous blogs











More recommended blogs »

Here are posterous posts filed under xmpp...

nrek says...

Gonna keep this short.

If somehow you’ve been dead online for the past few days, Google started to invite people to use Google Wave (http://wave.google.com); I didn’t ask for an invite, but they invited me. To my surprise, the only thing I could think of when I looked at this… thing, was “What’s it giving me?”… the next thought was, “Why is everyone wanting me to invite them to this thing?”.

It’s a mess of information, a collaborative messaging and sharing system, and the interface allows you to see typos on the fly when creating a “Wave” that others are associated with. Yippy. Perhaps the eager developer in me was expecting “The Jesus” of applications since everyone’s been buzzing about Google Wave for months. Now that I have it, I don’t really think it’s the next greatest internet thing evar!!!11 – more like, a step in a direction that might get somewhere later. It’s either that, or I’m just too old school with emailing and actually not being allergic to clicking my mouse to see video & things that my friends send to me. Dunno.

Overall, I’m not utterly floored. I would, however, like to see some of the UI features in Wave be ported to Gmail. I have 7 invites left. Entice me to send you one, and I’ll think about it, only to share the pain of trying to understand WTF  you’re looking at with me, I reckon.

Filed under: xmpp

zuwiki says...

In XMPP, there are three types of stanzas that can be sent between entities.

  • Presence stanzas declare an entity's availability. Offline, available, unavailable, in a meeting, at school, having a bad day and not wanting to talk, or anything else. At the lowest level, however, it is an on-off switch; either present or absent.
  • Message stanzas are a "fire-and-forget" way of getting a piece of information from one entity to another without worrying about getting anything back or even about whether or not it is actually delivered. Messages can have any kind of payload.
  • Info/Query stanzas, also called IQ stanzas, are transmissions that follow the request/response model familiar in the HTTP world. They even have a comparable set of verbs. An IQ stanza with a type of "get" is equivalent to an HTTP GET request, and a "set" IQ stanza is equivalent to HTTP POST or PUT requests. HTTP responses compare to IQ stanzas of types "result" and "error"

So the one piece of functionality that HTTP does well is the request/response model. On today's web, this is no longer practical for realtime bi-directional communication. However, for the purpose of fetching a web page, this model is perfectly fine. For this reason, the new XMPP web will most likely use XMPP's IQ stanzas for that purpose. Here is a simple illustrative example:

Filed under: xmpp

zuwiki says...

Here is the punch line: I am going to make a web browser and server that use XMPP to communicate rather than HTTP.

Here is the current status: when you visit a website, your browser talks to it using HTTP, which was meant to work like this: your browser sends an "HTTP request" and the server sends back a response, and that's that. That was fine for what they were doing with the web in the 80s, but now we want more interactivity. So along came JavaScript, allowing dynamic and interactive manipulation of webpages that had already been downloaded (via an HTTP request). The main two things that were missing were the ability to get new information from the server with out reloading the page, and the ability to send information to the server also without reloading the page. Then they made the XMLHTTPRequest JavaScript method, which allowed XML (or anything really, it's actually a misnomer) to be sent from JavaScript code directly to the server (over HTTP), thus forming an XML HTTP request (get it?). This is what we use now, but it still has a major problem: the web browser must initiate the request. Currently, most dynamic sites use polling to get info from the server. That is, they periodically say to the server "Hey, is there anything new?" and if there is, the server will send back the new information. But this is slow, stupid, and takes a lot of resources. The newest approach is to replace polling with a technique called "comet" which basically means that the web browser just makes one request, saying "Hey tell me when there is something new" and the server sends it's response but does not terminate the HTTP connection, leaving it open to send new information down when it arises. This is freaking stupid, for several reasons, the most important of which (and the only one I'm concerned with) is that HTTP was simply not built for that.

My solution (although I am certainly not the first to think of it): the web browser, instead of making HTTP requests to servers, initiates XMPP sessions with them. XMPP, or eXtensible Messaging and Presence Protocol, is the underlying protocol used by many instant messaging systems, notably Jabber and Google Talk. When they say that XMPP is extensible, they mean it. There are 200 something proposed extensions to the XMPP-Core specification, as well as a great many proposed extensions to the Jabber instant messaging specification (which is itself an extension to XMPP).

So making an XMPP extension oriented toward web server/client interaction will certainly be possible, and likely not terribly difficult. In fact, what gave me this idea is that Google Wave actually uses XMPP for much of its communication, including for federation between Wave servers. The open source Google Wave Prototype server is actually a component meant to be run alongside an XMPP server (the instructions use the OpenFire XMPP server, but people have gotten it working with other XMPP and Jabber servers, such as ejabberd).

Filed under: xmpp

abotis says...

Handy to install, works with google talk (XMPP) or United Internet supported protocols (gmx, web.de).

Filed under: xmpp

kineticac says...

Inviting a friend to join you in some real time application is an easy concept, but hard to do from the perspective of that real time app.  You need near instant response from a friend, and what better way than to find a friend who's online and available through protocols used by chat applications?

For a web application that only requires one request to find all online users, and then another request to send an invitation, a full fledged chat client is overkill.  Why build out a fully working client that scales with millions of connections, just to get a buddy list of all your online contacts?  Unless you're building Meebo you really don't need this.

I was trying to solve that very problem, invite online friends!  Google Contacts Data API did give me all the people in a Google contact list, but provided me nothing other than a last update sort.  Last updated contacts wasn't going to cut it.  So I turned to writing a XMPP type request.

Since I'm using the Ruby on Rails framework for this application, I decided to use the XMPP4R gem.  It's probably the most currently developed and up to date gem out there for XMPP and Ruby.

The Roster Helper that is bundled with XMPP4R has a handy way to get your initial buddy list, online and offline users alike.  The problem is, the XML response will not include presence updates.  The roster helper does do some kind of presence updates of it's own, but it was too inconsistent to use.  The correct way to deal with presence as an XMPP client would be to wait on a callback for presence updates.  The initial update would send you all of your online buddy's statuses.

First set up the Jabber client in order to connect to the GTalk XMPP server:

 

        cl = Jabber::Client.new(Jabber::JID::new(email))

        cl.connect('talk.google.com', 5222)

        cl.auth(password)

 

This above creates a new client connection with Google Talk.  The connect command accepts a server, which for GTalk is 'talk.google.com', and the port 5222.  5222 is the standard for most XMPP servers.  Next is the tricky part where you want to write a callback for presence updates:

 

# get the roster

        roster     = Jabber::Roster::Helper.new(cl)

        mainthread = Thread.current

        roster.add_presence_callback { |item,oldpres,pres|

  # code I left out in here populates the name, jid, and presence stuff

  # see the xmpp protocol response docs for specifics on how to get the info

          @list  << {:name => name, :jid => jid, :presence => pres.show.to_s}

        }

 

The roster is first initialized, and we set up a presence callback.  In this callback, we just populate a list of buddies represented as a hash.  Name is their nickname you've given your buddy, the jid is the jabber id.  In GTalk, the jid is actually just their email address.  Presence hash that I put together is actually their availability status, which can be one of the following: away, do not disturb, extended away, nil.  Nil is just available and online.  

Notice that we also save the current thread as our main thread, this is important because we're going to block this thread until we get a few seconds worth of initial presence updates:

        # send initial presence

        cl.send(Jabber::Presence.new.set_show(:dnd))

 

        # continue thread after timeout

        t = Thread.new { sleep XMPP_REQUEST_TIMEOUT; mainthread.wakeup;}

 

        # block thread

        Thread.stop

To get GTalk to start calling the callback function, send an initial presence of the current user.  In this case I'm sending do not disturb using the :dnd symbol.  The next section is where I create a new Thread, that sleeps for a specified number of seconds, then wakes the main thread up.  What does this all mean?  Well keep looking, right after I have that new thread created, I block the current one.  The current thread is the main thread, the one that's doing the fetching of online buddies.  The client's browser is still waiting until the mainthread starts up again.  Notice that we just wait for some amount of seconds before continuing, with NO indication of how many or if we have gotten all of our online buddies.  That is the shaky part.  I noticed that waiting 2 - 3 seconds gets all of my online friends, and using some "loading" graphic on the browser page keeps people from bailing out.  Each callback has it's own thread, so to keep them from spawning over and over again, we need to kill the client connection.

So the main thread blocks right where we say Thread.stop, and continues on to render the page after we wake the main thread up.  After we wakeup the thread, we immediately close the client connection, and go on to rendering the page with your populated list of online friends:

        # kill client connection

        cl.close

 

In the view code, we simply run through the array of friends and display their statuses.  We then allow people to click and invite their friends to the site immediately.

A lot of the code has been stripped out or simplified from what we've actually used, but you'll get the point.  If anyone has feedback, suggestions, or comments, please post them!  I'd love to see how to better solve this problem.

Filed under: xmpp

andyc says...

Check out this website I found at im.wordpress.com

Interesting. Read and post to WP.com using XMPP.

Filed under: xmpp

hdknr says...

PubSubHubbub Core 0.1 -- Working Draft

Abstract

An open, simple web-scale pubsub protocol, along with an open source reference implentation targetting Google App Engine. Notably, however, nothing in the protocol is centralized, or Google- or App Engine-specific. Anybody can play.

As opposed to more developed (and more complex) pubsub specs like Jabber Publish-Subscribe (Millard, P., Saint-Andre, P., and R. Meijer, “Publish-Subscribe,” .) [XEP‑0060] this spec's base profile (the barrier-to-entry to speak it) is dead simple. The fancy bits required for high-volume publishers and subscribers are optional. The base profile is HTTP-based, as opposed to XMPP (see more on this below).

To dramatically simplify this spec in several places where we had to choose between supporting A or B, we took it upon ourselves to say "only A", rather than making it an implementation decision.

We offer this spec in hopes that it fills a need or at least advances the state of the discussion in the pubsub space. Polling sucks. We think a decentralized pubsub layer is a fundamental, missing layer in the Internet architecture today and its existence, more than just enabling the obvious lower latency feed readers, would enable many cool applications, most of which we can't even imagine. But we're looking forward to decentralized social networking.

GAEを念頭においています。

JabberのPublish-Subscribeとは違って、とてもシンプルです。
巨大なパブリッシャやサブスクライバに必要とされるようなすごいことはオプショナルです。
基本プロファイルはHTTPベースでXMPPではありません。

極端にシンプルにするためにいくつかの選択を行いました。AかBの場合、”Aのみ"というようにして実装任せというようにはしませんでした。

PubSub空間での議論の状態を満たすかそれを越えていると思います。
ポーリングはやめよう。分散されたPubSub層が本質的で、今日のインターネットアーキテクチャでかけているものであり、そして明らかに遅いフィードリーダの有効にする以上存在感がクールなアプリケーションを実現するでしょう。その多くは想像もできないものです。
でも、われわれは分散されたソーシャルネットワーキングを目指しているのです。

Filed under: XMPP

hdknr says...

This project uses XMPP (AKA Jabber) to provide IP connectivity to an XBee wireless network. This is accomplished with a Gateway instance that forwards XBee packets to XMPP Clients and similarly receives XBee packets from XMPP Clients and forwards them to the XBee network. The purpose of this project is to allow an XBee wireless network to be shared by multiple applications that may reside on different machines and even different networks! As long as you can connect to an XMPP server, your XBee network and Clients can reside behind firewalls and/or NAT devices and still talk to each other. This project is built on XBee-API and Smack API and is supported on Windows, Mac, Linux and any other OS that supports Java 5+ and RXTX (RXTX for Gateway only).

Filed under: XMPP

hdknr says...

About gloox

gloox is a rock-solid, full-featured Jabber/XMPP client library, written in C++. It makes writing spec-compliant clients easy and allows for hassle-free integration of Jabber/XMPP functionality into existing applications. gloox is released under the GNU GPL. Commercial licensing and support are available.

Latest stable version: 0.9.9.7

Latest development version: 1.0-beta7

Filed under: XMPP

Olark says...

I’ve been trying to replicate the Hab.la experience on AIM and on MSN since around July of 2008. Today, after working on this problem off and on for far too many months, improving the existing pure python libraries for OSCAR (AIM’s protocol) and MSN, and finally rewriting everything using libpurple (the brains behind meebo, pidgin, adium, and finch). I have to admit defeat (at least in the short run).

It appears that the rate limiting on both MSN and AIM, makes it far too unreliable to try to build a bot, that sends a high number of status messages to the AIM and MSN servers (key to some of the protocol hacks I needed to make it work). After trying a lot of hacks, and getting everything working for small numbers of concurrent users, I’ve decided to stop bringing webusers online and offline as visitors come to your website – I could not stand behind the reliability of the service. From now on MSN and AIM users will have access to a limited version of Hab.la where they will not be able to easily initiate conversations with visitors to their websites. Although, their visitors will have no problem initiating conversations with them, and operators can still attempt to follow particular users by sending the message “/follow” to a webuser buddy on their buddylist.

We may add a few other modes of use for these protocols to make it easier to initiate conversations in the future, or bring back the old method if we can decrease our MSN or AIM ratelimit effectively, but this is unlikely to be a high priority in the near future.

We continue to recommend either connecting to Hab.la directly using a Jabber(XMPP) client. Or using Hab.la with an existing Gtalk or Jabber client. You will be able to take advantage of all of Hab.la’s features with either of these two approaches. Most notably: monitor visitor location on a website and initiate conversations directly with these visitors.

Filed under: xmpp