Atmosphere 3 Features and ROADMAP

[jfarcand]

Release Date: September 2015

Transparent HTTP/2 Support

Portable Layer on top of current Servlet/Netty HTTP/2 implementation. Transparent fallback to WebSocket, HTTP/1

JDK 8

Baseline Java version will be JDK 8 Issue

Servlet 3.1

Baseline Servlet version will be 3.1 Issue

Reactive Manifesto

Add support and comply to Reactive Manifesto Issue

Support for Atmosphere 2.x, minimal migration path.

• Broadcaster API supported
• Annotations API supported
• AtmosphereInterceptor API supported
• Injection API supported
• OSGI compliant
• Nettosphere API supported
• All atmosphere-extensions supported
• Servlet Based Framework like Jersey, PrimeFaces, Vaadin, etc should still be supported.

Core development

1. Atmosphere Runtime: New AtmosphereEmbedded API Issue
2. Atmosphere Runtime: Refactor AtmosphereFramework.java, remove all get/set Issue
3. Atmosphere Runtime: Trim AtmosphereRequest and AtmosphereResponse, exposes native Request/Response object Issue
4. Atmosphere Runtime: Remove Servlet API dependency Issue
5. Atmosphere Runtime: New JDK Lambda Friendly API, replacing AtmosphereHandler/AtmosphereResourceEvent. Based on AtmosphereResourceEventListener callback Issue
6. Atmosphere Runtime: EventBus for event message based Issue
7. Atmosphere Runtime: Server Side Javascript Support via Nashborn. Allow 100% Javascript Server side support like Node.js Issue
8. Atmosphere.js: Improved Atmosphere Protocol using JSON body instead of Query String Issue
9. Atmosphere.js: Support for event based messages like Socket.IO Issue

Dropped API

• Drop support for atmosphere-jersey API (Jersey 1.x) Issue
• Drop support for Meteor API Issue
• Drop support for AtmosphereHandler/AtmosphereResourceEvent Issue

[flowersinthesand]

Nice to see this and some words:

• Isn't it too early to make Java 8 baseline?
• For 8, I think query string is fine.
• For 9, you need to consider how binary data should represent event as well. (JSON is enough for text data) It was a kind of challenge to me.

[jfarcand]

@flowersinthesand JDK7 will be EOL next month. For *8, we want to support Message Acknowledgement which need to be in the protocol itself. Hence uery string support will be dropped.

For *9, http/2 will do the work for us as well as websocket. For other transport we will stick with what we support right now.

[flowersinthesand]

OK. The roadmap all looks great. I'll keep watching and share my thought. Keep up the good work!

[martin-g]

Depending on what you mean "around the corner" I also think it is a bit early to require Java 8 as a minimum. There are quite more apps in production running on JRE 7 than on 8. But I also don't expect these apps to migrate right away to Atmosphere 3.x so maybe it is fine.

@papegaaij Meteor is scheduled for removal. We will have to rework Wicket-Atmosphere.

[jfarcand]

@martin-g If the Meteor removal is an issue, I'm open to discussion :-) Since Meteor is a wrapper around AtmosphereHandler, the new #1919 can probably be extended to support Meteor.

For JDK 8, let's see what the rest of this community have to say. I don't have any issue supporting JDK 7, just need feedback :-)

[martin-g]

I guess migrating to a new API (e.g. AtmosphereHandler) won't be hard so there is no need to keep Meteor.

[gdrouet]

IMHO I prefer the @jfarcand idea and directly to jump into JDK8. With the JDK7 EOL, many environments should start their migrations after the next months. Yes many of them may stay under JDK7, as they kept JDK6 (even sometimes JDK5) when only JDK7 was still maintained. For many legacy apps running in JDK6/7 environment, Atmosphere 2.x should be fine.

Moreover, supporting JDK7 does not bring additional value to the framework, contrary to JDK8 which should really help us to improve Atmosphere at many points.

The issue is the same for other frameworks, we should check how they deal with that. I spoke with a Spring guy and the day they will migrate, they also think to require JDK8 without any JDK7 transition, however I don't think they will do that soon.

[slovdahl]

I'm also in favor of a Meteor-like API in the future. Migrating to a new one if Meteor is dropped probably won't be an issue in my case unless there are big fundamental changes.

[tekacs]

Comment to track (so that I get notifications).

[bhanubhakta]

Like the roadmap. Seems very interesting.

[mdekrey]

We're considering adopting Atmosphere as a Java abstraction over websockets with fallback to long-polling/streaming, but noticed that it's been marked for removal in this document. Is that still accurate?

We've found that certain corporate networks still block web-sockets but allow for long-polling, and so this is a must-have feature for us for adoption.

[mdekrey]

Noticed that this post is really old, but got a reply over in the google groups, in case anyone else is concerned about the same issue.

[jfarcand]

Next official version https://github.com/Atmosphere/Atmosph4rX