The first alpha of Vibe is at the API level not much different from a set of Portal 1.1+, Portal for Java 0.8+ and wes 0.1+. If you've used them, migration is not a big deal. But if you've created and used your own portal server and client, you need to modify your implementation a little bit. Take a look at reference implementation from Vibe Protocol.

However if you are hesitating migration, see the following advantages of Vibe over Portal that will help you make decision.

• For writing real-time web application itself.
  • While Portal has focused on ease to implement server first as it has started as a jQuery plugin for HTTP streaming and rejected any idea which could make protocol complex no matter how useful it would be, Vibe focuses on ease to write real-time web application itself more than anything else so is willing to accept any ideas if it's worth.
• Based on own protocol.
  • Portal has under the implicit protocol provided only two implementations: JavaScript client and Java server, but Vibe will provide various implementations including the previous ones based on its own explicit protocol so that it would be certainly easy to use Vibe in other language.
• Easy to write and verify implementation.
  • Portal's protocol is clearly separated to the very protocol part that have to be implemented and the extension part that can be optionally implemented, and on top of that, Vibe provides reference implementation and test suite to help write and verify your implementation.
• Merged with Atmosphere.
  • Vibe is also a result from a collaboration of Atmosphere and Portal. Useful features and detailed experiences of Atmosphere like performance tuning, binary handling, workaround for I/O platform's quirks will be available in Vibe.
• Leaded by Donghwan Kim and Jeanfrancois Arcand.
  • Jeanfrancois Arcand, an author of Grizzly, Asynchronous HTTP Client and Atmosphere, also leads Vibe. His rich experience in Java enterprise application and open source project will doubtless help Vibe out.
• On the superior community.
  • As Atmosphere 3, Vibe will inherit the good parts from Atmosphere. One of them is the superior community. Atmosphere has been developed and maintained by warm participation of the community. Now Vibe will be.
• Commercial support.
  • Now you can safely mitigate the risk to use a work from my one man show. Asnyc-IO, the company behind the Atmosphere, provides commercial support for Vibe as well.

Portal

Portal is heavily refactored and separated into Vibe JavaScript Client providing vibe.js that is successor of portal.js and Vibe Protocol providing reference implementation and test suite helping implement the protocol.

Installation

All about renaming.

• JavasScript files are renamed to vibe.js and vibe.min.js.
• Node.js module on npm is renamed to vibe-client.
• Bower package is renamed to vibe.

API

All deprecated or unuseful options and methods are removed or modified.

• portal module is renamed to vibe.
• portal.find is removed.
  • It has brought confusion when loaded by module loaders.

Socket options

• lastEventId is removed.
  • It is only valid when the server assures the message-sending order which is far from ideal in a performance.
• prepare is removed.
  • It has brought inconsistency when connection sharing is enabled.
• idGenerator is removed.
  • A form of socket id is fixed to UUID.
• urlBuilder and params are removed.
  • Attach them as query string in advance.
• inbound and outbound are removed.
  • Modifying final event object is not allowed.
• notifyAbort is removed.
  • It's always enabled to maintain reliable HTTP connection.
• credentials is removed.
  • It's always enabled for convenience of use of cross-origin connection.
• xdrURL has no default implementation.
  • No more support for JSESSIONID or PHPSESSID. Do it yourself.
• streamParser is removed.
  • The stream format is fixed to the event stream format from Server-Sent Events.

Socket

• option(key:string) is removed.
  • No reason to retrieve option.
• data(key: string, value?: any) is removed.
  • Create a map on open event and destory it on close event.
• on(handlers: {[event: string]: Function;}) is removed.
  • Use on(event: string, handler: Function) signature.
• one(event: string, handler: Function) is renamed to once.
  • For better readability.
• send(event, data, done: string, fail: string) is removed.
  • It was created to make callbacks work with connection sharing. Now connection sharing will be rewritten so that the other signature allowing to pass function will be available.
• Shortcuts to add event handler whose type is (handler: Function), i.e connecting, open, message, close and waiting, are removed.
  • For potential usage.
• It is not allowed to send event when socket is not opened.
  • Do that on open event.
• In dispatching message event, the second argument, reply, is changed from a function into an object to control reply.
  • Its type is {resolve: (data?: any) => void; reject: (data?: any) => void}, hence the previous reply(val) equals to reply.resolve(val).
• Sending and receiving binary event is not supported.
  • Use a plain WebSocket.

Portal for Java

Portal for Java and wes are renamed to Vibe Java Server and Vibe Java Platform respectively with many bug fixes and enhancements. If you are using Portal for Java less than 0.8, see migration guide to 0.8 first of all.

Installation

All about renaming.

• Group id is changed to org.atmosphere.
• portal artifact is renamed to vibe-server.
• portal-testsuite artifact is replaced and removed by the protocol test suite in Vibe Protocol.
• Each wes bridge artifact, wes-${platform}, is renamed to vibe-platform-server-${platform}.

API

All about renaming.

• io.github.flowersinthesand.portal package is renamed to org.atmosphere.vibe.server.
• io.github.flowersinthesand.wes package is renamed to org.atmosphere.vibe.platform.server.
• Each wes bridge's package is changed to contain platform's version at the end i.e. from io.github.flowersinthesand.wes.servlet to org.atmosphere.vibe.platform.server.servlet3.

After one year of work, it is my pleasure to announce that the first alpha of Vibe is released as the next version of Atmosphere.

Vibe has started since I shared experience on creating Yet Another Atmosphere as an effort to make Atmosphere a better project. After long discussion with Atmosphere's community and lead, we decided to start from scratch having better API and extension points in mind and to extract the protocol as a separate project to make it easy to use Vibe with any language.

Vibe is simple! For working example, please refer to the quick start guide of Java Server and JavaScript Client.

Server server = new DefaultServer();
server.socketAction(new Action<ServerSocket>() {
    @Override
    public void on(final ServerSocket socket) {
        socket.on("echo", new Action<String>() {
            @Override
            public void on(String data) {
                socket.send("echo", data);
            }
        });
        socket.on("chat", new Action<String>() {
            @Override
            public void on(String data) {
                server.all().send("chat", data);
            }
        });
    }
});

vibe.open("http://localhost:8080/vibe")
.on("open", function() {
    this.send("echo", "An echo message");
    this.send("chat", "A chat message");
})
.on("echo", function(data) {
    console.log("on echo event:", data);
})
.on("chat", function(data) {
    console.log("on chat event:", data);
});

Here is a summary of key features in Vibe overall:

• Based on protocol - Real-time web will be everywhere soon. You will need more features to write a just simple real-time webapp. The separated protocol is the baseline to build such features.
• Polyglot - It’s not just for Java and JavaScript but for any language. Thanks to the reference implementation and test suite, it’s easy to not only implement the protocol in any language but also verify implementation.
• Web standards - As component of the protocol, RFC and W3C standards are adopted. You don't need to do much to implement the protocol. Just use existing implementation as desired.
• Reliable full duplex connection - 8 transports implementing WebSocket as well as Streaming and Long Polling are designed for all on the web by carefully considering their known issues.
• Concise high-level API - You don’t need to be aware of low-level details like which transport underlies a socket and its quirks. Focus on how you will handle a given socket either by client or server only.
• Event based - The unit of data to be sent and be received from the semantic point of view is the event object associated with a customizable type rather than plain text message, which is easy to compose a controller from MVC.
• Protocol extension - Protocol extension is a pattern or feature to make the best use of full duplex connection for modern web application development. Features will be provided as protocol extension.
• Reply - Reply is a protocol extension, which allows for the sender to attach callbacks in sending event and for the receiver to call them with the result of the event processing in receiving event. It’s useful where simple event-notification is not sufficient like Acknowledgement and Remote Procedure Call.
• Lightweight client - In case of JavaScript Client, it takes 5.92KB minified and gzipped. Compare it to others: Socket.IO 1.1.0 - 17.77KB, Sockjs 0.3.4 - 10.09KB and Autobahn latest - 36.27KB.
• Broad browser support - According to the browser support policy following the one of jQuery 1.x embracing Internet Explorer 6, transports are designed.
• Connection sharing on browser - Socket can be shared and used across multiple tabs and windows as long as browser session is alive and they work as a single client to server.
• Simplified server - All interface you need to know to handle Java server is Server producing and managing socket and ServerSocket representing the remote client. Select some sockets from server and do something with them like handling DOM using jQuery.
• Tag - Unlike a socket that is just a connection from a specific client, the tag gives you a way to handle a specific entity in the real world as an identifier of a group of sockets. You can use it to model a user logged in using multiple devices and subscribers to a specific topic.
• Dependency injection friendly - A use case with Dependency Injection framework is definite. Define a server as a singleton component and inject it wherever you want to handle socket just like using EntityManager from Java Persistence API.
• Scalable - Shared nothing architecture is adopted to scale application horizontally with ease. What you need to cluster application is just a Message Oriented Middleware supporting publish and subscribe model.
• Run any platform on Java - Because Java server is built on Vibe Java Platform, which is a simple abstraction layer for full-stack web application frameworks and raw web servers running on Java Virtual Machine, you can run your application on any supported platform seamlessly. Now Play framework 2.x, Vert.x 2.x, Atmosphere 2.x, Servlet 3.x and Java WebSocket API 1.x are supported.

And here is the future roadmap of Vibe:

• Migration guide - A guide for Atmosphere 2.x users.
• Full Atmosphere 2.x concepts support - Broadcaster, BroadcasterCache and AtmosphereInterceptor concepts support.
• Help migrating other framework - Special help, patches and pull requests for all framework integrating Atmosphere.
• Handshaking - An entry point for authentication and protocol negotiation.
• Transport calculation - A process to find the very working transport for a given situation.
• Authentication - A helper for authentication like cookie-based model and token-based model.
• Replaceable event format - A separated serializer/deserializer per a socket to allow to replace the event format with one supporting use of binary data.
• Enhanced connection sharing - A protocol-level support for multiplexing logical sockets over a single physical connection.
• HTTP2 - New transports based on fresh new HTTP2.
• Transport API - API to add/remove custom transports.
• Annotation-driven API - A declarative way to handle socket using annotated POJOs.
• Event buffering - A means for tagged sockets to make up for missing events over their life cycle.
• Standalone - A standalone server where you don’t need a separate platform.
• Handling binary data - An ability to handle WebSocket binary message and to read HTTP request with binary body.
• Reading data by chunk - An efficient way to read very big data.
• Netty platform - A platform to run application on Netty.
• Spring platform - A platform to run application on Spring framework.
• Error handling - Consistent exception hierarchy and an action to handle such errors.

For full documentation and information on Vibe, please visit the website.

Please feel free to ask any questions and give me your feedback about Vibe. It will make Vibe better and better. I look forward for you to join the Atmosphere Groups and let people know what you think as I did to make Atmosphere better and finally could get an opportunity to create Vibe as Atmosphere 3.

Last but not least, the creator of Vibe offers professional support for projects Vibe team maintained through Async-IO, the official sponsor of Vibe. You can bring out features in the roadmap or custom features you’ve wanted by priority and mitigate risk from introducing Vibe into your project and using the alpha stage work.