The mysterious behavior of Mac Mail and Yahoo! Mail Plus

If you, like me, uses Mac Mail as your primary email client and you also have an Yahoo! Mail Plus subscription (which gives you IMAP access to your Yahoo Mail account), you may have experienced an intermittent connection behavior where the email client is not able to connect due an invalid password even though you're using the correct one.

I've been reading lots of blog posts and forums reporting the exact same behavior and I was not able to find a concrete answer but the following approach seems to be working for me so far.

So, next time you see that dialog box requesting that you enter your password again to login to Yahoo, go to your web browser of choice and navigate to Yahoo Mail (mail.yahoo.com).

If you are automatically logged into the system then make sure you click on the Sign Out button first.

When you return to the login screen, type your username and password normally but make sure you select the Keep Me Signed In checkbox and then click Sign In. That should solve the problem.

Have fun...

An Introduction to STOMP

STOMP (Simple (or Streaming) Text-Oriented Messaging Protocol) is a simple text-oriented protocol, similar to HTTP.

STOMP provides an interoperable wire format that allows clients to communicate with almost every available message broker. STOMP is easy to implement and gives you flexibility since it is language-agnostic, meaning clients and brokers developed in different languages can send and receive messages to and from each other. 

There are lots of server implementations that support STOMP (mostly compliant with the STOMP 1.0 specification). The following is a list of STOMP 1.0 compliant message servers:

• Apache ActiveMQ – http://activemq.apache.org

• Apache Apollo – http://activemq.apache.org/apollo

• CoilMQ – http://code.google.com/p/coilmq

• Gozirra - http://www.germane-software.com/software/Java/Gozirra

• HornetQ – http://www.jboss.com/hornetq

• MorbidQ – http://www.morbidq.com

• RabbitMQ - http://www.rabbitmq.com/plugins.html#rabbitmq-stomp

• Sprinkle - http://www.thuswise.org/sprinkle/index.html

• StompServer - http://stompserver.rubyforge.org/

On the client side, there are many implementations for a vast number of technologies. Below, you will find the libraries available for the most popular languages.

Language	Libraries
C	libstomp - http://stomp.codehaus.org/C
C++	Apache CMS - http://activemq.apache.org/cms/
C# and .Net	Apache NMS - http://activemq.apache.org/nms/
Flash	as3-stomp - http://code.google.com/p/as3-stomp/
Java	Gozirra - http://www.germane-software.com/software/Java/Gozirra/
Objective-C	objc-stomp - https://github.com/juretta/objc-stomp
Perl	Net::Stomp::Client - http://search.cpan.org/dist/Net-STOMP-Client/ Net::Stomp - http://search.cpan.org/dist/Net-Stomp/
PHP	stomp - http://www.php.net/manual/en/book.stomp.php stomp-php - http://stomp.fusesource.org/documentation/php/book.html
Python	stomper - http://code.google.com/p/stomper/ stomp.py - http://code.google.com/p/stomppy/
Ruby on Rails	stomp gem - https://rubygems.org/gems/stomp  activemessaging - http://code.google.com/p/activemessaging/

STOMP is an alternative to other open messaging protocols such as AMQP (Advanced Message Queueing Protocol) and implementation specific wire protocols used in JMS (Java Message Service) brokers such as OpenWire. It distinguishes itself by covering a small subset of commonly used messaging operations (commands) rather than providing a comprehensive messaging API. 

Because STOMP is language-agnostic and easy to implement, it’s popular to application developers and technical architects alike. STOMP is also text-based. Since it does not use binary protocols like other message brokers, a wide range of client technologies work with STOMP, like Ruby, Python, and Perl.

STOMP is simple to implement, but supports a wide range of core enterprise messaging features, such as authentication, messaging models (point to point and publish and subscribe), message acknowledgement, transactions, message headers and properties, etc.

The Definitive Guide to HTML5 WebSocket

The book is on the way now! You can pre-order it here. It has been so much fun and a lot of work but I personally hope you can get a copy and enjoy all the content we're putting together.

Here is part of the book description if you want more information about it:

"The Definitive Guide to HTML5 WebSocket is the ultimate insider’s WebSocket resource. This revolutionary new web technology enables you to harness the power of true real-time connectivity and build responsive, modern web applications.   

This book contains everything web developers and architects need to know about WebSocket. It discusses how WebSocket-based architectures provide a dramatic reduction in unnecessary network overhead and latency compared to older HTTP (Ajax) architectures, how to layer widely used protocols such as XMPP and STOMP on top of WebSocket, and how to secure WebSocket connections and deploy WebSocket-based applications to the enterprise. Build real-time web applications with HTML5."

The book gives you an overview of HTML5 WebSocket, the WebSocket API and the protocol, the high level protocols you can use on top of WebSocket, security aspects and enterprise deployment. 

The WebSocket bufferedAmount attribute

If you have been working or planning to work with HTML5 WebSocket you may end up transporting large amounts of data and/or you may have the requirement to transport data as fast as possible. 

The WebSocket object has an attribute called bufferedAmount that's particularly useful to check for the amount of data buffered for transmission to the server. You can use the bufferedAmount attribute to check the number of bytes that have been queued but not yet transmitted to the server.

The values reported in that attribute don’t include framing overhead incurred by the protocol or buffering done by the operating system or network hardware.

The code below shows an example of how to use the bufferedAmount attribute to keep sending updates every second, if the network can handle that rate, or at whatever rate the network can handle, if that is too fast.

// Buffering threshold at 10k

var THRESHOLD = 10240;

// Create a New WebSocket connection
var mySocket = new WebSocket(“ws://echo.websocket.org/updates”);

// Listen for the opening event
mySocket.onopen = function () {
 setInterval(function() {

// Check for amount of data buffered but not sent yet //and then send an update in case there is nothing //in the buffer

if (mySocket.bufferedAmount < THRESHOLD)

                                    mySocket.send(getUpdateData());

                  }, 1000);

};

Using the bufferedAmount attribute can be useful for throttling the rate at the applications send data to the server avoiding network saturation.

Checking for WebSocket Support on Your Web Browser

It’s frustrating to execute some code and don’t see anything happening after that. But, depending on the web browser you or the end user running your application is using that may be impacting the WebSocket functionality at this point since not all current browsers in use support HTML5 WebSocket natively yet.

So, let’s take a look on some techniques to make the web browser supports WebSocket.

We are going to use the JavaScript console available in all web browsers to start with the WebSocket support investigation. Each web browser has a different way to initiate the JavaScript console but if you’re using the suggested web browser (Google Chrome) take a look on the following resource to learn more about it (https://developers.google.com/chrome-developer-tools/docs/overview).

If you open your browser’s interactive JavaScript console and evaluate the expression window.WebSocket you should see the WebSocket constructor object:

 function WebSocket() { [native code] }

which means that your web browser supports WebSocket natively.

The same test above in some other browsers comes back blank or undefined indicating no native support.

If you want to add that capability for WebSocket support to your application or on our sample client code, you can use the following approach.

By just adding the following conditional check to your code before you try the WebSocket connection then it would be enough to tell you if the web browser supports WebSocket natively.

if (window.WebSocket){
     console.log("BROWSER SUPPORTED");
} else {
     console.log("BROWSER NOT SUPPORTED");
}

If your target web browser doesn't support HTML5 WebSocket and you want to have that amazing capability on your application, it's time for you to look into some vendors like Kaazing where you have WebSocket emulation that enables any browser (modern or not) to support the HTML5 WebSocket standard APIs.

From the developers perspective they can work in a fully transparent environment, using the client libraries that enable them to simply code against standard WebSocket APIs. And from the end-user point of view, they interact with a WebSocket application that Kaazing’s WebSocket emulation technology kicks in when native WebSocket support is unavailable, giving the user a seamless experience.

There are several web sites available on the Internet to help you with compatibility, not only WebSocket, but also HTML5 features in general. To mention a couple of them, you can navigate to http://caniuse.com/ or http://html5please.com/ and check for the HTML5 feature you want to use on the target web browser manufacturer and/or version.

The WebSocket readyState attribute

The WebSocket object will report the state of its connection through a read-only attribute called readyState.

There are four different values that the readyState attribute can receive to represent the state of the connection.

0 - CONNECTING – The connection has not been established yet.
1 - OPEN – The connection has been established and messages can be exchanged between the client and the server.
2 - CLOSING – The connection is going through the closing handshake.
3 - CLOSED – The connection has been closed or could not be opened.

When the WebSocket object is first created its readyState is 0, indicating that the socket is CONNECTING.

Inspecting WebSocket Frames

So far, it has been a challenge for us working with HTML5 WebSocket to analyze the traffic going back and forth from the client to the server and from the server to the client. Without using packet sniffing tools like Wireshark or tcpdump the analysis and debugging of WebSocket messages is almost impossible.

But, recently, things are changing and it's now possible to see frame data along with arrows indicating the direction of the data is going to.

A WebKit patch has been created and you can use Chrome Canary to check the latest changes and start inspecting WebSocket frames. A huge advance for those working with HTML5 WebSocket.

There is also a step-by-step demo located here: http://blog.kaazing.com/2012/05/09/inspecting-websocket-traffic-with-chrome-developer-tools/