B. Mann Consulting

I have the great pleasure to announce Pretzel -- a Jabber server written in Python on the Twisted framework.

The two main authors are Ralph Meijer, well known as a long time member of the Jabber community, and Andy Smith, hacker extraordinaire.

For now, Andy checked in some experimental code hosted on Google's new code repository. Check it out at http://code.google.com/p/pretzel/. We're looking for other people to join in -- one of the reasons we started the project was because it seemed there were a lot of people looking for the same thing. It is available under the MIT license to make it potentially usable by the broadest number of people, as well as being under the same license as Twisted.

Please join us on the pretzel-dev list and we'll get the discussion going. 

What's on the roadmap? Well, this is a very early release -- more of a proof of concept. We hope to enable the quick and easy implementation of various JEPs, making it fun and simple to add all sorts of powerful features to the server and clients, truly showing how Jabber can go way beyond "just" instant messaging.

I'm in Stuttgart meeting with some clients. Lots of Drupal + Jabber integration talk, and luckily ralphm is here to bring along lots of Jabber expertise.

We've been talking a lot about geolocation notification over Jabber -- so users can indicate their location over Jabber. There are few (if any?) clients that support this today, so we'll probably support some short hand for testing purposes -- being able to type in geoloc:[lat],[lon].

So, I was looking at JEP-0080 (geoloc) and JEP-0112 (physloc). 112 is a plain text representation of physical location, and JEP 80 is the latitude / longitude. JEP 80 also has a plain text "description" field. So...why not collapse the two? physloc could replace the current JEP 80 "description" entry...every single entry is optional, so the text field in physloc can handle the current usage of the description field. It just seems wasteful to maintain two separate JEPs for what is essentially the same information.

As well, if a service already knows the physical location, it can send it along with the geoloc -- you can't derive the physical location from the geolocation, so in the current case, you would have to send two messages.