Planet Jabber

September 02, 2010

Process One

TextOne for iPhone, with photo sharing!

Our iPhone version of TextOne, the simple and fast messenger for smartphones, has received a nice photo sharing feature.

TextOne, the simple, light and fast smartphone messenger, is now offering a new feature to share photos with your friends.

Easy, a new icon appears at the top right of the conversation screen, you just need to tap it.

There, you can choose to take a picture or select one from your albums... and add the text you wish.

This will appear in the conversation as a taped instant photo, like any other messages.

You can also browse the photos exchanged with your contacts.

Of course, this also works with TextOne Pink!

Photo sharing in TextOne will let you share good moments with the people to whom you are close. Or alternatively play ;-)

And finally, you can play with it

by Nicolas Vérité at September 02, 2010 08:51

August 31, 2010

Thiago Rocha Camargo

Yet about Google Call

Due the amount of comments and emails received, I will reply to them in a post.
  • How does the Authentication works?
    • That is one key reason for using their established XMPP channel for placing the calls. The user is already authenticated in GMail and Google Talk. So the request is sent through the authenticated XMPP network to their XMPP Component responsible to offer SIP Gateway. From that moment one the component will convert the Jingle Signaling from the Google Talk to SIP and use your Google credentials to authenticate in their SIP Services.
  • Which Codec is being used?
    • G711 is the only one that I could trace, although the Plug-In indeed support iLBC and others. The reason behind it, is that G711 is a supported codec in most all PSTN, Media Gateway or other interconnection with Legacy Telecom. Alternatives would be transcode, which is out of the question due CPU load, drop of quality etc... Or use proprietary G729 which requires the payment of extremely high royalties per client/channel.
  • Will they succeed in making money?
    • Google "Cows" may produce some "milk", but I doubt Google consider that as an important income resource. The feature is much more related with PR and positioning about THE REALTIME company, than anything else. Having most of what Skype does in their closed client, in a browser and using open technologies is a direct confront to Skype's model. IMHO, Phone Numbers are dead, and will be ripped out of the market in less than 5 years from now. 
  • Are the API for Audio/Video Streaming available for third-party usage?
    • That I could not figure out. Tried document or formal info from Google without success. May someone could assist us on that matter with some Javascript reverse engineering, or a Google guy, that wanna share that with us. Please let us know :)
  •  Is there any client supporting it already?
    • No, it is not yet available in any client that I'm aware. But I bet that as soon Google appears with a formal specification and documentation, that will happen very very fast.
Thanks for all the questions, I hope I have answered most of it.

by Thiago Camargo (noreply@blogger.com) at August 31, 2010 19:59

August 27, 2010

Thiago Rocha Camargo

Google Call over Jingle with a SIP Gateway on their XMPP Server



I just confirmed in my Wireshark that Google Call on Gmail uses exactly what I recommended in a previous post back in 2009 when they acquired Gizmo5. And YES, it's Jingle!
Their wise choice of having a portable and extensive protocol(XMPP) as the bus and having specialized technologies like SIP, will grant them a flexibility never seen before on platform and device portability.
Their master plan is to be able to delivery mass market a cheap and alternative method for calling the old fashioned telephone numbers. And sure they have the right platform and tools in their hands:

Android


Almost all Android phones have with GTalk application pre-installed, which already runs a nice XMPP Client, besides other great alternatives like Nimbuzz.

Now imagine what Google can bring to the market without much effort due their choice of using Jingle extension of XMPP for their service? Google Call support on Android phones. That is the key and reason behind this service.



Overview Diagram:

by Thiago Camargo (noreply@blogger.com) at August 27, 2010 07:54

August 26, 2010

Ignite Realtime Blog

Openfire 3.7.0 beta has been released!

Good things come to those who wait!

 

The Ignite Realtime Community is pleased to announce the beta for the next release of Openfire. This release contains a number of important  fixes and improvements to stability and XMPP protocol compliance. You can find a full list of fixed issues here. This beta is also the first version of Openfire to be released by the Ignite Realtime community under the Apache License v2.0.

 

You can download the 3.7.0 beta release here. Please provide us your feedback on the Ignite Realtime support forums. It would be helpful if you would tag your comments, discussions and questions with a tag that reads "openfire370beta"

 

As always, but particularly since this is a beta release, make sure to backup any existing version of Openfire and the persistent storage that it uses, before upgrading!

 

Some important security related notes to this release:

  • Openfire no longer ignores the system property to disallow password changes via XMPP. With previous releases, it was not possible to prevent users from changing their password via their XMPP connection. (CVE-2009-1596)
  • Fixed a XSS attack on the admin console login form.

 

Protocol compliance improvements:

  • Publish Subscribe (PubSub)
  • BOSH (http-bind) xml namespace compliance fix.

 

Some highlights of this beta release:

  • Improves how Openfire handles "idle" connections. Some of you may have  the system property xmpp.client.idle set to -1 to work around  previously broken behaviour. You may now let it default to 6 minutes or  set it to your preference.
  • Improved Openfire's caching to be less prone to memory exhaustion by correctly calculating cache size usage.
  • Fixed a bug where admin console login into a newly installed Openfire server would fail until restarted.
  • Fixed a bug with shared rosters within a LDAP environment.
  • Openfire now ships with the latest JRE (1.6.0u21).
  • A memory leak with the Personal Eventing Protocol (PEP) was fixed.
  • Openfire's custom log interface has been replaced with SLF4J and a Log4J backend.
  • Fix issues with self signed SSL certificates.
  • A number of improvements and fixes were made to the Multi-User Chat (MUC) configuration pages on the admin console
  • There were also some improvements made to the plugins.
  • There are also French, Russian, and Lithuanian langauge translation fixes for Openfire and some of the plugins.

by Ignite Realtime Blog (communityadmin@igniterealtime.org) at August 26, 2010 21:05

The State of the Ignite Realtime Community

You probably have noticed many recent changes with Ignite Realtime! Thanks to the help of Benjamin Sherman of Jive Software, the entire suite of Ignite Realtime servers and infrastructure have been migrated to a Contegix hosted location external to Jive. This was done so that the community could take administrative control of Ignite Realtime and push projects forward as we wanted without relying on help from Jive Software.

http://www.igniterealtime.org/images/ignite_logo.gif

So has Jive Software abandoned Ignite Realtime? No! They continue to generously fund the infrastructure and colocation costs at Contegix.  They also will participate with the community when appropriate. The community is now in tasked with moving projects forward!

 

So how will this work? At the moment, there is a handful of active community members that have been working hard to get the infrastructure setup. This infrastructure includes:

 

logo_atlassian1.png
jive-darkgloss-2600x1300.jpg

 

So who is running the show here? We currently do not have any formal community leadership process in place. The handful of us that are currently getting the infrastructure setup have been working together to make decisions to move Ignite Realtime forward.  With more community involvement and interest, we'll certainly wish to formalize roles and responsibilities soon.

 

So when will project X on Ignite make a new release? Depends Here is a brief summary of the various projects status:

  • Openfire is very close to a 3.7.0 beta release. Guus der Kinderen and others have been working hard to squash remaining bugs and get a formal beta release out the door.
  • Spark continues to struggle along and sure could use some developers to help get a formal release out the door. Please let us know if you are interested in helping out.
  • XIFF released version 3.0.0 just this week thanks to the work of Mark Walters. Congratulations on the new release!
  • Smack has seen recent development and could use more developers to help progress things along.
  • Tinder is developed by Guus and he continues to make improvements to the library projects like Openfire uses.
  • Spark Web has not seen development on Ignite for quite some time. Community member Dele Olajide has made a number of improvements to spark web on the version he maintains offsite.
  • Whack could use some development help, so please let us know if you are interested.

 

At the end of the day, the productivity of the Ignite Realtime Community depends on you! We have been given the power to push projects forward as fast as we wish, so let us take advantage of this wonderful infrastructure setup provided by Jive Software.

 

Onward and upward!

by Ignite Realtime Blog (communityadmin@igniterealtime.org) at August 26, 2010 18:00

Google Talkabout

Call phones from Gmail

(Cross-posted from the Gmail Blog)

Gmail voice and video chat makes it easy to stay in touch with friends and family using your computer’s microphone and speakers. But until now, this required both people to be at their computers, signed into Gmail at the same time. Given that most of us don’t spend all day in front of our computers, we thought, “wouldn’t it be nice if you could call people directly on their phones?”

Starting today, you can call any phone right from Gmail.



Calls to the U.S. and Canada will be free for at least the rest of the year and calls to other countries will be billed at our very low rates. We worked hard to make these rates really cheap (see comparison table) with calls to the U.K., France, Germany, China, Japan—and many more countries—for as little as $0.02 per minute.

Dialing a phone number works just like a normal phone. Just click “Call phone” at the top of your chat list and dial a number or enter a contact’s name.


We’ve been testing this feature internally and have found it to be useful in a lot of situations, ranging from making a quick call to a restaurant to placing a call when you’re in an area with bad reception.

If you have a Google Voice phone number, calls made from Gmail will display this number as the outbound caller ID. And if you decide to, you can receive calls made to this number right inside Gmail (see instructions).

We’re rolling out this feature to U.S. based Gmail users over the next few days, so you’ll be ready to get started once “Call Phones” shows up in your chat list (you will need to install the voice and video plug-in if you haven’t already). If you’re using Google Apps for your school or business, then you won’t see it quite yet. We’re working on making this available more broadly - so stay tuned!

For more information, visit gmail.com/call.

Posted by Robin Schriebman, Software Engineer

by Jason (noreply@blogger.com) at August 26, 2010 17:52

August 25, 2010

Thiago Rocha Camargo

Google Call on GMail


Google Call, as I mentioned before in a previous post, was added as a Calling feature direct to the browser.
I hope this take down Skype monopoly built on top of a closed and proprietary fuzzyware.

Google now has the most powerful position on VoIP world and soon will take down Skype eagerness for a proprietary/closed network.

Google's solution is built on top of a plugin, which is embedded on new Chrome and also easy to install on other browsers. They are using Standard XMPP and Jingle at Client Level with SIP in the backend, Streaming RTP with Standard Codecs directly from the browser. ( NO CRAP FLASH TRANSCODE USED! )

Google Call offer several advantages:
  • Browser Based
  • Open, so they can make use of third-party clients for it ( Do you need more reasons??? )
    • VoIP everywhere, browser or in your favorite Client. Solid Model.
Hope Nimbuzz adds support for it soon!

You can try it here: http://www.google.com/chat/voice/


As you asked how it works:
Google is making use of recent acquired GIPS Company Technology to add native RTP streaming directly to the browser.
For PSTN Termination, Google is using Gizmo5, together with previous Google Voice partners.
I promise to post deeper technical information like protocol details and Codec later on.

by Thiago Camargo (noreply@blogger.com) at August 25, 2010 18:39

August 24, 2010

Ignite Realtime Blog

XIFF 3.0.0 has been released!

 

We are pleased to announce the release of XIFF 3.0.0!

This major release includes many bug fixes, improvements, and features over the previous beta release, including Digest-MD5 support and removal of all Flex dependencies for pure AS3 project support. This release also includes a new class namespace (igniterealtime instead of jivesoftware).

You can view the full change log here.

 

Download XIFF from here.

 

Nightly builds are also maintained for XIFF now. You can access those here.

 

Enjoy!

by Ignite Realtime Blog (communityadmin@igniterealtime.org) at August 24, 2010 20:24

Dave Cridland

Violating Layers

There’s a raging argument going on in WebSocketLand (ie, the hybi@ietf.org list), between Shelby Moore and – well – everyone, about layered designs in protocols. I shared my views, but I thought it might be interesting to some of you lot, my imaginary readers, so I repost here.

To give you some context, the subject of channel binding was being raised as an interesting, and positive, application of layer violations.

On Tue Aug 24 03:32:28 2010, Shelby Moore wrote:

In the ideal way, one would first connect with say TLS, then Upgrade to the Authentication protocol, which would interact with the encrypt layer in a standard API, and then the higher layer would interact with the Authentication layer through another standard API.

FWIW, this is more or less how it happens, just with an ordering change.

One first connects with the application protocol (and there are several we might choose, such as XMPP). Next, a layer insertion happens, inserting TLS. Next, a second layer insertion occurs, inserting SASL. The SASL layer may communicate with the TLS layer for authentication or channel binding – both are abstract concepts, and could be done with an abstract API. Finally the application layer continues.

If you accept the conceit of layer insertion – and why not – then you can use the existing layer model just fine. Adding layer insertion also helps conceptually with compression techniques like XEP-0138 or RFC 4978, which insert a compression layer into the stack.

However, it’s important to recognise the distinction between a model, which is a method for people to understand and discuss particular areas of the overall functionality, and the reality.

In reality, the authentication provided by TLS, if any, is mediated by the application – which controls authorization, and therefore needs to ascertain whether the TLS credentials (typically an X.509 certificate) can be used to authorize the session. Similarly, SASL communicates back to the application protocol to translate from a username to whatever the application deals in (which can be similar or wildly different – for XMPP, a Jid; for LDAP, a DN). So as long as you don’t look too closely, the layer model holds, but in many areas, the boundaries are blurred.

There’s two important things to remember, though:

  1. In abstract terms, the layers exist, and are reusable. Thus generic TLS and SASL libraries can, and do, exist, and applications can use them.
  2. But the layer model is just a model; it is there for humans, and doesn’t produce any inherently better overall solution. By limiting the amount of knowledge required at each layer, though, it allows us to work around human limitations and achieve good solutions via combining specialized expertise. So I get to treat TLS as a “magically secure” thing for exchanging certificates and “doing security”, and TCP is “just a pipe”.

If anything, it’s the human expertise that really follows the layer model – as an application protocol guy, every time I need to know something new about TLS or TCP in order to properly code a client or server, that’s the kind of layer violation that I really care about.

Of course, the worst layer violation is the one where we force the user to have to have significant understanding of some portion of the stack. (We do this far too often, by trying to explain X.509 strong authentication to users in Firefox, and trying to explain the intricacies of unauthenticated addressing in internet mail).

by dwd at August 24, 2010 08:29

August 23, 2010

Remko Tronçon

Swift 1.0-beta6 released

It’s been a while since we released the previous Swift beta. As a result, the sixth beta is quite packed with bugfixes, speedups, and general improvements. The list of changes is too long to describe here, so head on over to http://swift.im/releases/swift-1.0beta6/ for details and downloads of the last Swift beta, and let us know what you think in the MUC room – swift@rooms.swift.im.

by Remko Tronçon at August 23, 2010 19:54

August 22, 2010

Ignite Realtime Blog

Tinder 1.2.2 has been released

We  have just released Tinder  1.2.2, which is a maintenance release. It  fixes a number of bugs, features improved performance and has a number  of new features.

 

Download Tinder from: http://www.igniterealtime.org/downloads/index.jsp

by Ignite Realtime Blog (communityadmin@igniterealtime.org) at August 22, 2010 06:39

August 20, 2010

Peter Saint-Andre

Administrivia

Since upgrading to WordPress 3.0.1 recently, I’ve noticed that the category-specific syndication feeds seem to be broken. I’ll have to fix that so the folks at Planet Jabber don’t get bored with my posts about philosophy and such…

by stpeter at August 20, 2010 03:23

Google Talkabout

Use Linux? Now you can video chat too

(Cross-posted from the Gmail Blog)

If you’ve been wanting to use voice and video chat on Linux (our top video chat request), then we have good news for you: it’s now available! Visit gmail.com/videochat to download the plugin and get started. Voice and video chat for Linux supports Ubuntu and other Debian-based Linux distributions, and RPM support will be coming soon.

Posted by Tristan Schmelcher, Software Engineer

by Jason (noreply@blogger.com) at August 20, 2010 00:55

August 19, 2010

Process One

Tsung 1.3.3 has been released

Tsung 1.3.3 fixes severals bugs. It fixes support for SSL with erlang R14A.

Tsung 1.3.3 brings some minor bugfixes.

  • fixed parent proxy not working in 1.3.x (tested with 1.3.2 and 1.3.0).
  • fixed url substitution is broken in some cases
  • fixed Tsung not using sessions with low probabilities
  • fixed SSL not working with erlang R14A
  • fixed failure when a proxy is used and an URL substitution is set
  • fixed HTTP cookies support when a proxy is used
  • fixed hanging at the beginning using distributed setup
  • fixed "if" statement, which is not allowed in a transaction

by Marek Foss at August 19, 2010 16:29

August 18, 2010

Peter Saint-Andre

The Value of Friendship

My friend Dizzy just pointed me to a fine essay by Daniel Akst on friendship (or the lack thereof) in modern society. It’s no surprise that I would enjoy the essay, given that I’m a big fan of both Aristotle and Epicurus, that I have written two essays on friendship, and that I have re-published essays on the topic by Emerson, Montaigne, and Randolph Bourne over at monadnock.net. Good reading!

by stpeter at August 18, 2010 03:26

August 17, 2010

Tobias Markmann

GSoC '10: Final Report

This is my final report on my Google Summer of Code 2010 project. During the last three months I've learned quite a lot about Psi's and Iris' codebase and implemented most of what's been planned.

I started off implementing a new SASL mechanism, SCRAM-SHA-1, in Psi which will be used if no external SASL library is available.
Using this mechanism users can login securely even over unencrypted connections and if they want Psi to remember their password, this can be done more securely if SCRAM-SHA-1 is available at the server.
More on this part here.

The second part of the project was implementing Stream Management, XEP-0198, in Psi. Luckily, Matthew Wild, one of Prosody's main developers, started to implement it around the same time so we could easily test each independent implementation against each other.
I've implemented the most important and interesting parts of XEP-0198: stanza acknowledgment and stream resumption. Together they make chatting, but basically everything in XMPP, more reliable.
Especially stream resumption is nice in case your connection is dropped. In this case you don't have to go through the whole roster retrieval and presence distribution steps again. The stream resumption part wasn't that easy to implement, because currently Psi destroys its complete XMPP stack state on disconnection with the server.

During the last couple of weeks I've added a new groupchat join dialog to Psi. This included reusable data models for browsing server room listings, bookmarks and history of joined rooms. Additionally the new dialog lets you choose more than one room to join. I've also modified the still existing old join dialog (It still exists because it also handles join logic.) to support bulk join. This means if you join multiple rooms on login, due to bookmarks, or via the new join dialog, the dialogs indicating join process are hidden as long as no error occurs.

It was quite interesting getting to know Psi's and Iris's codebase which are from quite varying design quality considering their parts but most of the time it was quite understandable and Justin, Psi's and Iris's original and main developer, was always able to answer my questions on the code and design.
Coding in the GSoC umbrella organisation XSF was quite fun and well organized. The weekly meetings helped to keep you on track and frequent reports from fellow student kept you up to date on their projects' progress.

All the developed code is available at my github account.

by Tobias Markmann at August 17, 2010 10:58

August 13, 2010

Peter Saint-Andre

A Book Idea

While travelling in Europe a few weeks ago, I thought of a book I’d like to write:

Don’t Buy This Book, You Can Read It for Free on the Internet!
The Closing of the Copyright Era, the Open-Sourcing of the Book, and What it All Means for Readers, Writers, and Publishers

Not that I’ll have time to write it anytime soon…

by stpeter at August 13, 2010 02:33

August 08, 2010

Tobias Markmann

GSoC '10: New Join Dialog Finished

I finally got the new join dialog for Psi finished.

New Join Dialog for Psi

When the dialog opens it shows you the rooms available at your server, if there are any, your recently joined rooms and your bookmarked ones. At the top you simply enter the nickname which you want to use to join the rooms.

There's little special about this dialog and it works how you'd expect it to work, hopefully. If you want to give it a try yourself the code is available here.

by Tobias Markmann at August 08, 2010 14:36

August 07, 2010

Tobias Markmann

libidn vs. ICU benchmark in string prepping

Due to Waqas's asking for months now I've finally got around and made some benchmarks on two string prepping libraries. The one being libidn, as far as I know most XMPP servers use this and the other being ICU by IBM.

libidn is LGPL licensed and ICU is MIT licensed.

Current XMPP standard says that every JID must be string prepped so if you don't want to cache because of memory reasons your string prepping routines are called quite often. It turns out ICU is much faster than libidn. For this benchmark I tested a couple of strings and let them go through nameprep, resourceprep and nodeprep profiles via string prepping.

The result is that ICU is about 60 times faster in string prepping. Version of libidn being 1.15 and of ICU being 4.2.0.1.

The source code package of the benchmark is attached to this node. It falls under GPLv3 license.

by Tobias Markmann at August 07, 2010 22:41

August 05, 2010

Dave Cridland

In Memoriam Google Wave

So. Farewell
Then
Google Wave.

Interesting
research project.

And much-hyped product.

Yes. You popularized
Operational Transform.

Yet ignored
the practical problems,

Of fork lift upgrades.

[Guest post by E. J. Thribb, (17½)]

by dwd at August 05, 2010 09:38

August 04, 2010

Dave Cridland

iPhone4, IMAP, Lemonade, and more

The blog post that we did at Isode, IMAP Enhancements in iPhone OS Update (iOS 4), a little while ago, sketched over the surface of why Lemonade is still quite a handy thing (and perhaps explains why not only Apple, but Nokia, too, are still developing new Lemonade functionality).

Take ESEARCH. This was my first RFC, so perhaps I’m biased, but in the “old days”, it was aimed as a simple domain-specific compression mechanism to allow clients to obtain the same results as SEARCH itself but in a more compact form. We then threw in some additional magic, like MIN, MAX, and COUNT.

Now these days – unless you’re roaming at €3/MB, anyway – the numbers of bytes on the wire just isn’t that interesting. Until recently, when I upgraded my DSL line, my phone had more bandwidth than my workstation. Moreover, my phone is flat-rate (whereas now, my DSL isn’t, quite).

But what my workstation does have over my phone is that my phone does not have effectively unlimited power. If it’s pulling data at top-rate, it’ll last about 4.5 hours – a long time for a phone, too, but it’s an E71 with a chunky 1500mAh battery.

The way to avoid this drain isn’t just to not send data at full rate – sadly, that’s not nearly enough. You need to avoid sending data very much at all, and moreover, you want to keep packet sizes under 128 octets if even remotely possible, to keep the radio in the much cheaper FACH, rather than more expensive DCH, modes.

And that’s where ESEARCH comes in. By using a very effective domain-specific compression, then a large number of results can be transferred in a very small space – often, in fact, enough to fit in under 128 octets, if you’re lucky.

In fact, much of Lemonade works well like this – IDLE can send notifications about new mail and flag changes in a small amount of space, letting the device bring the radio up to fetch the content for many notifications all at once when it’s convenient. CONDSTORE and QRESYNC help to allow a full resync of a mailbox to squeeze in under the thresholds.

Although many of the design criteria were a bit different to the criteria for effective use of 3G, it turns out they’re sufficiently compatible that Lemonade is not only as relevant as it ever was for mobile email, it’s actually gaining importance fast. And, of course, that shows in the increased support in devices.

by dwd at August 04, 2010 10:04

Alexander Gnauck

a short MatriX development update

there were no blog posts for a while because I was too very busy with coding.
I released MatriX 1.3 for .NET some days ago. This release includes many new features.
To name only some of the latest updates:

  • SASL EXTERNAL
  • SASL SCRAM-SHA-1
  • file tranfer control
  • XPath filering
  • roster versioning
  • …..

Yesterday I successfully compiled and tested MatriX on Windows Phone 7. MatriX for Windows Phone will be the next product to complete the MatriX series released very soon.
If you plan to develop XMPP apps for WP7 or need a XMPP layer for WP7 feel free to contact me.

by gnauck at August 04, 2010 10:01

August 03, 2010

Process One

ejabberd 2.1.5 and exmpp 0.9.5 bugfix releases

We are pleased to announce the bugfix releases ejabberd 2.1.5 and exmpp 0.9.5.

Regarding ejabberd 2.1.5:

The main changes are:

  • Erlang/OTP R12 support fixed
  • Erlang/OTP R14A support added
  • OpenSSL 0.9.8 or higher is required
  • BOSH: New optional connection attribute process-delay
  • C2S: Don't ask for client certificate when using TLS
  • C2S: Inform client that SSL session caching is disabled
  • CTL: Fix problem when FIREWALL_WINDOW options for erl kernel were used
  • CTL: Some systems delete the lock dir; in such case don't use Flock at all
  • Caps: Support all the hash functions required by XEP-0115
  • Config: Fix typo in --enable-transient_supervisors
  • Config: New configure option: --enable-nif
  • Extauth: Support parallel script running
  • MUC: Allow admins to see private rooms in disco
  • ODBC: Correct handling of SQL boolean types
  • ODBC: Discard too old queued requests (the caller has already got a timeout)
  • ODBC: Fixes wrong SQL escaping when --enable-full-xml is set
  • ODBC: Use ets instead of asking supervisor in ejabberd_odbc_sup:get_pids/1
  • Pubsub: Enforce disco features results
  • S2S: When logging s2s out connection attempt or success, log if TLS is used
  • Shared Rosters: When account is deleted, delete also member of stored rosters

Release Notes

Check the Release Notes for a more complete list of changes:
http://www.process-one.net/en/ejabberd/release_notes/release_note_ejabberd_2.1.5

If you upgrade from ejabberd 2.0.5 or older, read carefully the release notes of ejabberd 2.1.0 too, because there were several changes in the  installation path and the configuration options.

Links

The list of solved tickets since previous version is available on ProcessOne bug tracker:
http://redir.process-one.net/ejabberd-2.1.5

ejabberd 2.1.5 is available as source code package and binary installers for Linux 32 bits, 64 bits, Mac OS X Intel, and Windows:
http://www.process-one.net/en/ejabberd/downloads


Regarding exmpp 0.9.5:

Brief summary of changes:

  • Add method to retrieve underling connection properties
  • Configurable Zlib support
  • Fix BOSH that didn't work
  • Modify exmpp_component to use exmpp_socket instead of exmpp_tcp
  • Negotiate zlib compression before OR after SASL
  • Raise requirement to Erlang/OTP R12B-5
  • Replace calls to OTP module ssl_pkix with public_key
  • STARTTLS support
  • Session enhancements
  • Stream compression support for session

Links

exmpp home page:

http://support.process-one.net/doc/display/EXMPP/ or easier to remember: http://exmpp.org/.

Download exmpp 0.9.5 source code package from:

http://download.process-one.net/exmpp/

You can also check the ProcessOne Labs page:

http://www.process-one.net/en/labs/

by Jérôme Sautret at August 03, 2010 15:44

July 30, 2010

Tobias Markmann

GSoC '10: New MUC Join Dialog

Here another short update on my Google Summer of Code project.

I've designed a new dialog for Psi which should ease the process of joining a room. The new dialog's features include:

  • all sources of existing rooms in a single dialog
  • allow entering a JID of a room manually
  • select multiple rooms from server room list, history and bookmarks and join them at once
Currently I'm hammering out the last couple of models for the server room list and bookmarks/history views. To round up this small post, here a screenshot of the dialog: Screenshot of new join dialog.

by Tobias Markmann at July 30, 2010 21:41

July 27, 2010

Tigase Blog

The longest running XMPP service

I wonder what is the longest running XMPP service without a restart.

I watch a few servers running Tigase but then I restart them from time to time for software update with new features or bug fixes.

One of them is im.flosoft.biz which runs on quite old Celeron 1.33GHz machine with 200MB memory. Serves approximately 800 online users and works well for 75 days already without a restart. This is a development version of the Tigase 5.1.0 branch but indeed, Florian pushes me to release it as another stable version.

I have found however an absolute winner in this 'competition'. The last time I checked it earlier today the Tigase uptime time was: 657 days, 6 hours, 53 mins, 21 secs. This is a service running on MS Windows machine for online gaming website and most of the user connections are web clients connecting via Bosh. It is still running and working well!

I have also received a few other reports from people successfully running Tigase, as they say for 2 years without restart. If you have any specific data, number of days, the software version, please add a comment to this article. I would like to hear about your experience with long-running Tigase server.

read more

by kobit at July 27, 2010 18:56