Memory Leak

Careless Whisper, part 2: Habemus muc!

Bernd Fondermann — Fri, 4 Sep 2009 12:23:00 +0200

Jabber chat rooms have some advantages over IRC, like a more fine-grained participant control and other details. One advantage is that participants are identified from their jabber id, so there are virtually no 'ghost' participants and it's easy to have a private conference.

In the Jabber world, chat rooms are called 'multi-user chat' or 'MUC' for short. Vysper's MUC implementation has reached a critical milestone: users can create a room and chat with each other. Not everything is yet fully working.

Trying yourself is pretty easy if you have your Java5, Maven2 and svn ready:

svn co http://svn.apache.org/repos/asf/mina/sandbox/vysper/trunk vysper
cd vysper
mvn install -Dmaven.test.skip
cd server; cd extensions; cd xep0045-muc
mvn assembly:assembly -DdescriptorId=jar-with-dependencies -Dmaven.test.skip
cd ..; cd ..
java -classpath src/main/config/:src/main/resources:../extensions/xep0045-muc/target/xep0045-m1.0.0-SNAPSHOT-jar-with-dependencies.jar -Dvysper.add.module=org.apache.vysper.xmpp.modules.extension.xep0045_muc.MUCModule org.apache.vysper.xmpp.server.ServerMain

Windows users, please change '/' into '\' for 7.

Log into the server as "user1@vysper.org" or "user2@...", both have the identical password 'password1' and make sure you set the server/host configuration to 'localhost'.

The chat can be found under 'Service Discovery' or 'Services', depending on your client.

As a client, I recommend Psi, but others work, too. However, I didn't get Apple's iChat to log into Vysper yet.

Know IDEA, part 2: CSS editing

Bernd Fondermann — Fri, 21 Aug 2009 10:17:00 +0200

Ask the web programmer of your choice about a good IDE for developing CSS, HTML and JS. Most of them will recommend a simple text editor or a tool which is Windows only and not developed for at least 5 years...

Thankfully, I'm not a web programmer, but from time to time, I have my own little share in editing web frontend code. But I don't know CSS by heart. IDEA supports me with auto-complete in CSS files. It marks styles which are used nowhere in HTML.

It even displays a little colored box besides codes like "#628c78". Isn't that a beautiful color? Maybe not. Klick on the box and choose another one. Nice.

Now go to an HTML file, enter... <a class=" ...and invoke auto-complete. Now IDEA shows you a list with all defined CSS styles. Hitting Command-B on a class name brings you directly from HTML to the CSS declaration. That's the 'Integrated' in 'IDE'.

Careless Whisper, part 1: Wham!, what a summer.

Bernd Fondermann — Fri, 21 Aug 2009 10:12:00 +0200

What a summer for Apache Vysper, your friendly XMPP Server project. At first, we moved within Apache from Labs to MINA. Then we got our Google-Summer-of-Code hacker Michael Jackl, who worked successfully on the publish-subscribe extension. Currently Niklas Gustavsson from FtpServer fame is heavily working on Multi-user chat. Overall interest in the project increases.

Yet, we still have a long way to go from MINA's sandbox to a production ready server. Yet today, Vysper is easily embeddable and extendable while pubsub allows for many interesting applications outside the "Jabber world" of plain instant messaging.

Know IDEA, part 1: Column insert

Bernd Fondermann — Tue, 18 Aug 2009 11:42:00 +0200

Most of the day, I'm using one particular software: a Java IDE. I've tried Eclipse. It's nice and everything. But I've only found that one particular IDE really does (nearly) everything right for me. It gives me a big productivity boost. You know, those small features and gems that make your day. I'm using Jetbrain's Intellij IDEA.

IDEA has a column selection mode. (Menu -> Edit -> Column Mode) This fact in itself is nothing very special. Microsoft Visual Studio had column mode in the late 80ies, if I remember correctly. It was a hidden feature at first and proved very helpful over the years. Now, I'm no longer using the Visual suite and they seem to be far behind the IDE train.

Column mode is especially helpful when you want to replace the same text on multiple consecutive lines. You select one or more column on a couple of lines, just like you would select cells in a spreadsheet.

This selection can be copied and pasted around. Yeah!

What's not so obvious is that you can even paste a single line fragment that's already on your clipboard. And that's how it works: Select and copy some text with regular selection mode. Then switch to column mode, select a box and hit paste. What you now get is that the copied text is pasted to every single line of your box selection. A multi-paste.

This even works when the selected box is multiple lines, but zero columns. This way, you can prepend text on multiple lines at once, with one strike, without artifical replace constructs.

UPDATE: Emmanuel Lécharny has responded with how to do column mode with Eclipse. Thanks!

Disclaimer: I'm in no way affiliated with JetBrains. Really. I'm just enthusiastic and a little bit biased. That said, I'm a happy user of a free license for Intellij IDEA, due to my work on Open Source projects and I'm grateful for that.

XMPP at Google

Bernd Fondermann — Sun, 9 Aug 2009 09:31:00 +0200

After Google Wave, the company will again use XMPP, now for their Chrome browser's sync feature. Together with GTalk, this is the third high-level technology from Google featuring XMPP.

My guess is, it will only be a question of time until browsers will offer built-in XMPP protocol support, making HTTP and AJAX more or less void (I'm not kidding).

Greg Wilkin appears to be right when he notes that Wave will only use XMPP for server-to-server communications. Sync is planned to exploit Google Talk. And Google Talk does support client-bound XMPP connections. Of course, in the browser, the transport for XMPP is still HTTP.

At Apache, we've already started building an open source XMPP server, with my two heros Michael working on PubSub and Niklas starting implementing MUC - Multi User Chat (IRC done right). It's hosted at Apache MINA.

Sponsoring Open Source

Bernd Fondermann — Thu, 2 Jul 2009 18:18:00 +0200

Getting more involved with the ASF at large, coding time gets eaten up by overhead time, which can be summarized as 'managing projects'. A big part of this time is not actively managing, but reading coding- and non-coding-related mailing lists. And believe me, there is a lot to read these days.

Anyway, it's time to get some coding time back. There are three accounts to take from: 'family time', said 'ASF overhead time' or 'working time'. I'll try for the last one, since reducing the other ones is not really an option. And maybe, since my current customer project doesn't max me out 100%, this might be a good choice.

Being a freelancer, it's only going to work if I get paid for working on Open Source. And there are some big, important projects ahead:

getting Apache Vysper, the only ASL licensed open source XMPP server implementation ready for prime time (heard of "Google Wave" already?),
moving JAMES over into this century,
creating a modularized rsync implementation in Java (a private project of mine, waiting to be open-sourced),
getting a brilliant new webmail project at the ASF started (here's the code).

Now, here's the deal: If you sponsor me, I'll work on one if these projects, as your contractor, as many days as we agree on. One or more goals may be defined. The smallest working unit is a day (8hrs). Only coding time will count (including fixing bugs and creating documentation). Anything related to PM is still booked on the 'open source overhead' account, you'll have nothing to do with that.

You'll get an excellent discount rate from my regular closed source rate. Any output will go to the project under the ASL2.0, I retain copyright, the whole work is done in public. For any further work, customization or support not going directly to the project (but you) my regular rate applies.

This means: You control what I will be working on during sponsored time. If the project community doesn't accept my work, you'll get it instead. But our choice of Todos will make sure that it's something the whole project will benefit from and is very likely to be accepted.

If you think this could work out for you and you have a particular goal in mind get in contact with me at open.work@brainlounge.de.

I am available for coffee

Bernd Fondermann — Mon, 20 Apr 2009 00:00:00 +0200

This week I am at JAX'09, a massive german conference about Agile, SOA, eclipse, Java etc. I'd like to have a chat or a coffee with you. Just drop me a note at bernd@brainlounge.de.

Also, excitingly, my 6 weeks of conferencing and holidays finally come to an end. I'm currently available for freelancing in Frankfurt/Main, Germany or via telecommuting.

Where's my spec, where's my code?

Bernd Fondermann — Tue, 14 Apr 2009 16:17:00 +0200

The essence of XMPP (a.k.a Jabber) is specified in two RFCs, 3920 and 3921. Both are solid, reasonably readable documents. For actual implementations though, the current in-progress revisions, named with a "bis" appendix and a counter (like 3920bis-03), are more suitable. Better structure, more examples, more details. They contain all the lessons learned from the XMPP public lists at xmpp.org. But they are still moving targets.

Furthermore, every XMPP server implementation has to conform to another handful of non-trivial RFCs and a dozen of XEPs. It's hard to always know what code is implementing what part of which spec. This gets even more complicated where RFC and -bis contradict each other. How do we know which spec version is used by every developer?

That must have been the situation for Gerolf Seitz, when he was working on Vysper for a short time.

He proposed to annotate the source code with information about the related spec section. These annotations where unmaintained for a while, mostly because you can have only one annotation of the same type per element (class, method). Vysper is implemented following the bis's, but section numbering still changes slightly from revision to revision, which invalidates the annotations. Sometimes you want to link to more than one spec (RFC and RFCbis, bis-01 and bis-03, or differenct sections of the same spec). Now this is mostly resolved, and I am happy again with @SpecCompliant.

What changed?

At first, (not being very much into annotations) I found out how to have more than one @SpecCompliant at the same place:

             
@SpecCompliance(compliant = {
    @SpecCompliant(spec = "RFC3921bis-05", 
                   section = "3.3.3", 
                   status = IN_PROGRESS, 
                   comment = "current impl based hereupon"),
    @SpecCompliant(spec = "RFC3921bis-08", 
                   section = "3.3.3", 
                   status = NOT_STARTED, 
                   comment = "substantial additions from bis-05 
                              not yet taken into account")
})

As you can see, comments where added, too.

This gets very helpful. Now, different specs or spec revisions can be annotated side-by-side.

Using a standard JDK tool called apt (hope this link won't stop working for at least the next months) and writing some little glue code, a compliance overview doc can be generated, listing all SpecCompliant annotations in one HTML file. That's great. The table links out to the relevant spec section(s) and to the javadoc where this is implemented. For a snapshot example, see here.

Now it's easy to get an idea about our spec coverage and developers can jump directly to the spec from the relevant class or method.

The only thing we still need now is the power which automagically creates the implementation from the spec. Contributions welcome :-)

Speaking at JAX'09

Bernd Fondermann — Mon, 15 Dec 2008 07:41:00 +0100

At the JAX'09 conference in Mainz end of April next year I'll be giving three talks on the whole, wow. One will be about Apache Lucene. The second will be a short talk about Apache Hadoop, a project which will be hard to fit into 30 minutes.

And I'm especially excited to be able to speak about XMPP again, after the FastFeathertalk I gave at ApacheCon EU 08.

By the way, ApacheCon EU 09 is one month before the JAX and still nothing to be heard about the accepted sessions...

Start of german Lucene Online Series

Bernd Fondermann — Sun, 30 Nov 2008 18:53:00 +0100

My new online series about the Apache Lucene project and its different products went online this week at JAXenter which is also publishing german Java Magazin. It starts with a very basic introduction to the Lucene framework. Later episodes will cover Solr, Nutch and Tika.

XMPP Glorification (Part 1): IQ

Bernd Fondermann — Tue, 25 Nov 2008 22:42:00 +0100

I'm sure most of you developers know that situation: You are working on your day job and what you're doing is not really always the hottest thing on the technical earth, to say the least. So, some relieve and distraction is needed to recover at night. For the last 2 years I've been on-and-off working with XMPP (a.k.a. Jabber), implementing a server as a side-project. And that really gives me the kicks I need.

XMPP is a well-architected, well-standardized, powerful, yet reasonably simple messaging protocol. It was created with extensibility in mind and it has in fact lots of public and proprietary extensions, which all (if they adhere to the standard) are interoperable. (Which means: Any server or client can savely ignore them, if they don't know them.)

What makes XMPP such a natural choice for many messaging applications is that it supports the three major messaging paradigms: point-to-point, broadcast and request/response.

While the first two are used for communication between all clients with the server as a router (hub-and-spoke), request/response - or "info/query" (IQ) in XMPP terms - is used for client/server interaction.

XMPP is bound to a session based on a persistent TCP connection, much like POP3, SMPT, Telnet and similar line protocols. This is in contrast to HTTP which was architected session-less. That led to many workarounds to make sessions work between requests with HTTP, all those pains like cookies, encoding sessions in the URL, recycling TCP connections between request, long polling and whatnot. What once was considered an advantage of HTTP is becoming more and more a burden as servers are required to respond spontaniously to avoid client pull congestion.

Theoretically, with a persistent connection, the server can always push data to the client even when the client does not pull because he is off doing something else. But most of the established protocols like POP3 or Telnet refrain from doing so. And this has always been considered a good choice, since you as a server didn't want to overload your network and clients in times when network and CPU resources where precious goods.

In addition to client/server, XMPP supports server/client request/response, too. This does not create a problem since a XMPP client must be prepared to receive Messages and Presence from his peers at any time anyway. So if the server wants to know if the client is still alive, he can send him a ping IQ command and the client will respond with a pong.

To me it seems like XMPP opens the door for many new types of applications. It's developed by an open community but it lacks a server implementation which is open source in the ASF sense, with the right license and community setup.

So if you have some spare cycles, jump in and help out on Vysper at Apache Labs. See you there!

Looking for a new contract

Bernd Fondermann — Wed, 25 Jun 2008 08:47:00 +0200

My current freelancing contract is running out at end of August and I am starting looking for a new project, but only in the Frankfurt/Main area or remotely from my Frankfurt office.

I am doing Application Server/Java stuff, mainly using the Spring Framework, as customer are quite focused on this platform these days.

I am very experienced in the whole project lifecycle: doing customer workshops, writing specifications, laying out the architecture, training the development team, coding, testing.

So if you need someone for any or all of those tasks, drop me an email at bernd at brainlounge de.

Projects involving Apache projects Lucene, Hadoop or JAMES, XMPP/Jabber technology or Scala are especially tempting for me.

JAMES integration within Geronimo

Bernd Fondermann — Sun, 15 Jun 2008 22:41:00 +0200

That's great news. David Jencks managed to get the Apache James Mail Server running within Apache Geronimo. It's still experimental, but it's a big step forward. That's also why I started the effort making James Server run with Spring.

(How to scale) In the multi-processor world

Bernd Fondermann — Sun, 15 Jun 2008 22:02:00 +0200

At the time when I got into application development it was common that GUIs became unresponsive when applications (3D renderers for example) where busy calculating, or that you could not go on scrolling in a text while it was being saved. Multi-threading was the cure to this and threads were used to build multi-tasking applications. Having Threads as a feature in Java was a big plus for moving to it from C++. Off-the-shelve PCs had no more than one processor back then. Multi-core was unknown. It was sufficient to have one thread for the GUI, one for I/O and one or two for computations and you easily had maxed out your machine. Later came thread pools, for multi-plexing database calls, or scaling your web server to more clients.

But eventually, one thread per socket connection was no longer scaling well for a web server, either. There were too many concurrent threads to be handled efficiently by the OS. Every context switch between two threads has an overhead. That's when event-driven frameworks like MINA came to rescue. A thread was only assigned to a connection when there is data to process.

Today, multicore multi-CPU machines are very common. So we no longer need to optimize for our one-and-only processor. Instead, we need to optimize for threads running truely in parallel on the same machine. New sorts of bottlenecks start to appear: One of them is sharing variables between threads. Access to memory happens in a processor's local memory, so state has to be copied around between main memory and CPU-local caches (I am simplifying here).

There is a fascinating presentation by Joe Armstrong about how to scale in the multi-processor world over at InfoQ. He also wrote a book about it (amazon.de link). It's about Erlang, a computer language optimized for running on lots of processors and lots of machines. It is many years old and used in production, but only became better known to a wider public in the last years. And if you don't have enough of it then already, listen to the Erlang interview with Joe Armstrong by se-radio's Markus Voelter.

From expo to expo

Bernd Fondermann — Fri, 6 Jun 2008 09:10:00 +0200

Open Source Expo at Karlsruhe was not exactly overcrowed, but both of my talks went fine and I was really enjoying them. Mostly, because people seemed to be interested and asked really good questions. Christian Geisert from Apache OfBiz fame has some photos online. My slides (in german) are up at my apache homepage.

Now, the unaffiliated Swiss Open Expo in late September seems to be more of an event. Many Apache people are presenting, including Henning Schmiedehausen, Bertrand Delacretaz, Lars Eilebrecht and Brian Fitzpatrick. I'll be able to do a talk about Apache Hadoop. If you are able to come to Winterthur, don't miss it. I lived there for a short time, it was beautifully relaxing. And Zurich is just around the corner.

Becoming an ASF member

Bernd Fondermann — Fri, 6 Jun 2008 09:02:00 +0200

Today, I am happy and excited since I've appearently been elected as an ASF member. Thanks a lot! That's the greatest achievement in my professional life. And it's a pleasure and honour to be working together with all those great Apache people.

Community-wise, you are wrong every time

Bernd Fondermann — Mon, 26 May 2008 21:07:00 +0200

Open source projects aren't conflict free zones. People are trying to get along with each other most of the time, and sometimes this just doesn't work. That is life. We have to be prepared to be confronted with misbehavior, crossing of social barriers, accusations, misunderstandings, egos, cultures, you name it, when all we really want to do is hack cool stuff. That's the downside of working at really cool software projects. There are other developers you have to deal with. At Apache, conflicts mostly start or at least are fought over 'technical issues'. Everybody appearing publicly at Apache - users, committers, members - is ethically bound to communicate in a consensus-driven and open minded way. But if you really don't find a consensus, and every supposedly fruitful technical argument makes people angry, frustrated, annoyed or any other kind of bad mood, there is probably a more substantial underlying community issue ventilating.

Warning signs are statements like 'I know I am right, why do you insist in your position?', 'This [my opinion] is a known fact. Period.', 'Everbody knows this, but you!', 'Simply change your tool/IDE/settings/operating system/keyboard layout/brain and shut up!'. 'I don't like people telling me what to do.'

This happens when people became unable to let any other opinion approach to there minds that they seem to be shutting down for everything what everybody else is saying. The blue screen of discussion death, so to speak. They become very defending when in fact they there is no reason. Finding consensus becomes impossible.

What's the solution when such a situation emerges? That's really difficult. So, let me tell you "The Parabel from the Developer with the Server Bug":

Once upon a time there was a developer. He was programming against a server API. He laid out the client application brilliantly. He wrote tests, he reviewed the code. He even briefely talked to other developers about it. Then he let the client connect to the server. And all his excellent client was telling him is that there was a transmission error. Since he prepared his client program so thoroughly, certainly there was a bug in the server implementation. So he downloaded the sources (lucky him!) and looked into them. There he found ugly code, bad design, potential security holes. He ranted, he cursed. He thought about ways to torture the server app developer. He couldn't find the server bug, even less than the doomed soul writing this crap of a server. He turned away in disgust.

In the evening, he met a friend and told his story. They both shook their heads in disbelief about the misery with the server bug. At some point over the third cold beverage his friend asked the developer: Have you checked if it's a bug in your own client code? The developer just laughed.

Well, the next day the developer stumbled about a tiny little incorrectness in his own code, a probable misunderstanding of the server API spec. Small change. He started up his client again, and, can you believe it, everything just worked smoothly.

That's the end of the story. Is there anything to learn from this? In computer programs, you might be able to find a prove (test case, svn log, etc.) for who did wrong what and when. This is not the same for community issues. If a fight breaks out, and you are a part of it, you are wrong every time. Fighting is a community bug. Take a step back before blaming others. Fix your own errors first. Let the others fix their own errors first, too. Then go back to discussion. Be polite. Be overly careful with every single word. Be pragmatic. Try to find a consensus, even if it's only to have a consenus. All parties will be unsatisfied. Maybe it will be painful for you more than the others. Maybe you have to go through this multiple times. But you have created something beyond just coding. You fixed the community.

OFBiz booth at Open Source Expo 08

Bernd Fondermann — Sun, 11 May 2008 22:54:00 +0200

Apparently the guys from Apache OFBiz were smart enough to get a booth organized for their project at Open Source Expo 08 in Karlsruhe. Great!

ASF and Lucene Talks at openexpo.de end of May

Bernd Fondermann — Fri, 9 May 2008 09:41:00 +0200

I am surprised and happy that my two talks were accepted for Open Source Expo 08 in Karlsruhe, Germany. OpenExpo is a two-day event starting on Monday, May 26th, which is the only day when I will be attending.

I am especially excited about my general talk about The Apache Software Foundation at 16:50. I already have a rough outline of the talk, but if you'd like to give me some input about what I should definitively not forget to tell about the ASF, your input is much appreciated. Just post to community@apache.org or drop me a private mail at bernd dot fondermann at brainlounge.de.

The other session is an introductionary talk about Apache Lucene (at 10:20), similar to the one I gave in January at OSMB.

Also, if you'd like to meet, you find my cell phone number on the internet, or contact me over xing or linkedin.

Unfortunatly, the ASF - being one of the biggest and most successful communities in Open Source is not representing with its own booth on the expo floor. Hopefully we get one organized next year.

See you in Karlsruhe, the city with the most sun hours in Germany.

e-mail 1.0

Bernd Fondermann — Thu, 27 Mar 2008 00:40:00 +0100

While bravely fighting with the IMAP implementation in Apache James, Robert is hoping for relieve by new e-mail protocols. And indeed, it's high time. A lot of energy, both in productivity time and electrical power, is wasted. Wasted by huge piles of spam and other types of unsolicited e-mail. And this is not only a social phenomenon, it is made possible by the protocols used to transfer mail between computers. These protocols (SMTP, IMAP, POP) stem from the information technology middle ages. They are not appropriate for today's needs. We need something better. I don't talk about 'e-mail 2.0' here. We need 'e-mail 1.0', first.

So the proposed goal is to establish RMEP, based on HTTP and XML. I don't think HTTP is an appropriate prerequisite. HTTP is a client/server protocol. It is not designed for message transfer. It is designed for hypertext transfer in the request/response world. And yes, you can probably make every protocol or type of messaging working embedded into HTTP. But there is no way to hide that the protocol wasn't originally build for this purpose. The interesting parts of such a mail protocol would be contained in the XML part, though. So using HTTP only leads to a half-hearted solution. We would start from a broken protocol and end up with a new protocol embedded in an another-purpose host protocol.

The best would be to use a protocol which is especially designed for exchanging messages, both between client/server and server/server, which from the beginning supports security, encryption and compression and is extensible. Which is transport agnostic and uses XML as its syntactical foundation.

A protocol matching all this is already in broad use, it is well-specified and understood. Mature, if you want. It's called XMPP, Extensible Messaging and Presence Protocol. The community around XMPP is open and very welcoming. And if you want, you can even transport XMPP via HTTP. XMPP is not restricted to request/reponse (polling). The server can truely push to its clients which reduces network traffic and makes life easier.

XMPP is not RESTful. But access to a single message and complete message structures (trees of mailboxes) could be RESTyfied within XMPP. XEP-0013 could be a starting point. Mailboxes and storage would still need to be specified as separate XMPP extensions.

Let's just hope that in the end the next-generation e-mail protocol (be it RMEP, XMPP or something else) will be chosen for its technical merits and not only because of politics.

Joseph Weizenbaum passes away at the age of 85

Bernd Fondermann — Fri, 7 Mar 2008 22:02:00 +0100

A sad moment for computer sience and humanity in the information technology age as software developer, researcher and philosopher Joseph Weizenbaum died on March 5th (bios in en, de, the news in german).

He worked and taught for over 30 years at MIT but he always kept a healthy and quite entertaining critical distance towards computer and technology. He constantly reflected about our usage of information technology. And more than once he came to the conclusion: Don't use it this way!

He grew up in Berlin where he also lived for the last decade or so. When he was still a child his family luckily escaped Nazi Germany. Weizenbaum returned to the Nikolaiviertel neighborhood after his wife's death.

His great book 'Computer Power and Human Reason' had a major influence on me. Still highly recommended! His last article (german original), published on the day of his 85th birthday in german newspaper Sueddeutsche Zeitung is still laying on my desk beside the laptop. It is about the perception and interpretation of all the information which is accessible to us these times. The article's subtitle (printed version only) translates to: "Earth could be paradise, if only we were able to truely understand it."

Hackathon on ICE

Bernd Fondermann — Tue, 4 Mar 2008 23:31:00 +0100

What is the most comfortable way to get from Frankfurt to ApacheCon EU in Amsterdam? The plane takes you there in one hour but the whole trip takes you around 3 hours from city center to city center. It involves riding local trains, walking around at the airports, carrying luggage, and generally a lot of annoying queuing and waiting. The net time left for doing something productive, which of course can only be coding, what else, is reduced to 20 minutes or so. What a waste of time!

So when I will head for ApacheCon EU in a few weeks, I will board an ICE train at Frankfurt Central, plug in my laptop into the power plug (there is one for every two seats), put on my headphones and start coding away. Exactly four hours and hopefully many unit tests and bug fixes later my private Hackathon ends at Amsterdam Centraal and I am warmed up for the real ASF Hackathon.

The two to four hour distance is perfect for taking the train. It's comfortable, easily accessible, secure, flexible and fast. And the train is perfect for coding. The majority of development for Apache Vysper was done on ICE trains, same for the Spring adoption of Apache James.

By the way. If you can spare two extra hours and want some really nice views on your way between Frankfurt and Amsterdam, then go at 120 km/h, instead of 300, and take the 'old' route through the middle rhine valley with its picturesque villages, old castles, vineyards and mysterious Loreley. On this route you have to change trains at Cologne. Then you either face some unit tests and bugs or dream of maidens for the rest of the trip.

The X-S-Foundation

Bernd Fondermann — Tue, 26 Feb 2008 15:04:00 +0100

XMPP is a protocol which started out as 'Jabber' and was mainly intended for chat. It's still in heavy use for this purpose today, with its more prominent uses in Google's GTalk and Apple's iChat, but has grown far beyond that. The Jabber community took the effort and made it an IETF standard (RFC 3920 and RFC 3921). What makes XMPP a real workhorse are the many extension to the base protocol which make it an all-purpose messaging protocol.

All standardization is done by the XMPP Standards Foundation (XSF). The XSF very much resembles the ASF. Its members are individuals not companies, membership is granted for those with a proven XMPP track record. All business is completely done in the open. Everyone is encouraged to participate on the mailing lists.

But there are differences. Anyone can apply for membership. Every member must reapply once a year.

So it's a pity there are not so many ASF-licensed XMPP server implementations. That's why I started Apache Vysper over there at Apache Labs.