Roadmap for Restlet Framework

Introduction

This document contains a rather detailled roadmap for future Restlet version and is continuously updated to indicate the progress made and the adjustments necessary. The goal for next 2.x versions of the Restlet Framework is to develop incremental releases in a short time-frame of about 6 months.

Version 2.1

Finalize the developments

Especially fix the internal connector

Ease the usage of the Restlet framework

Automatically synchronize the central Maven repository

Via the the Sonatype OSS repository (see this page).

Documentation of releases

Code review or diff of code leveraging Github

Automate releases notes

Have a look of Github allows to generate changes logs using its API.

Production

Monitor the Web sites in order to detect when they are down (cf pingdom).

Version 2.2

Better community tools

Forge migration to GitHub

Over the past years, the GitHub service has gained a lot of popularity to host open source projects. Our goal is to migrate our source code repository and issue tracker from Tigris to GitHub. Beside the modern user interface, one major advantage will be the management of contributions via the "pull requests" feature. As a result, we will switch from SVN to Git.

User questions migration to StackOverflow

Over the past years, the StackOverflow service has gained a lot of popularity and many Restlet users have naturally started to ask their usage questions via this site. While initially hard to keep track of in addition to our regular mailing list on Tigris, we know think that this is more convenient for many kinds of questions.

The plan is to make this support more official and promote the usage of StackOverflow on Restlet web site. See the existing Restlet related questions.

Mailing lists migration to Google Groups

Taking into account the migration of the Restlet forge (source code, issue tracker and misc downloads) from Tigris to GitHub, the last remaining service will be our mailing lists. To simplify our community management tasks, we intend to merge both discuss@restlet.tigris.org and code@restlet.tigris.org mailing lists to the new version/UI of Google Groups.

Migration to Java SE 6

The main code trunk will be migrated from Java SE 5, that reached its end of life, to Java SE 6. We will look at taking advantage of new features added and will also leverage the new Servlet 3.0 API which requires Java SE 6 as well.

Migration to the Servlet 3.0 API

Size optimization of editions

Restlet editions for Android and GWT required special adaptations in version 2.0 to run in those restricted environments. In version 2.2, we want to go further into the customization effort, with a special focus on footprint.

Regarding Android, the core org.restlet.jar for Android contains the internal Restlet HTTP connector (client and server), but in many cases, we could just leverage the client connector based on Apache HTTP Client, especially because it is part of the Android runtime. We should therefore provide an addition org.restlet.jar file, without the internal connector but preconfigured to leverage Apache HTTP Client, resulting in a smaller footprint. Also, there is a Base 64 implementation in android.util that we could leverage as well as Apache HTTP Components 4.0 on the server side.

Regarding GWT, we added support for annotated interfaces and client proxies in version 2.0 with automatic POJOs serialization and deserialization, generated using GWT's deferred binding mechanism. When using those proxies, we rely on the whole Restlet Core (GWT edition) for the actual implementation, but this is mostly transparent unless the user needs to modify the underlying ClientResource for advanced use cases (authentication is a classic case).

In order to not add the footprint of the Restlet Core in those simple cases, we could optionally generate a lighter proxy relying directly and only on GWT's lower-level HTTP API and the classes needed for serialization and deserialization from GWT-RPC internal packages.

In addition, we will look into distributing several profiles for each Restlet module, like a client-side only "org.restlet-client.jar" and "org.restlet-server.jar" in addition to "org.restlet.jar". The Restlet API and Engine would be unchanged, just partially shipped in those JAR files.

OSGi Environments edition

We will enhance the edition for OSGi Environments added late in the Restlet Framework 2.1 development process, in order to take full advantage of the available OSGi core services, such as the log service and the HTTP service.

We will add an org.restlet.ext.osgi extension facilitating the development of highly dynamic Restlet applications, by integrating the code currently in the Restlet incubator. See this specification document for additional details.

Cache service

The Restlet API has a comprehensive support for HTTP caching metadata and directives. However, we have no built-in way to support client-side and server-side caching of actual representation content.

The plan is to provide a CacheService class with configuration option based on size, media type and so on, with a default behavior and a very extensible implementation to plug any kind of caching mechanism (in memory, on file, distributed cache, database, etc.). For details, see this specification document.

Restlet API

Beyond the above mentioned features, here are some additional ones that we are considering:

• Removal of deprecated artifacts in the API, engine and extensions to reduce size
• Consider a Container/Composite class, parent of Component and Application
• Restlets and resource classes contained in a Composite cannot directly manipulate objects outside their parent container
• Support server-side resource proxies based on Restlet annotated interfaces that would allow a POJO to become a stateful REST resource. Those objects would be thread-safe all potentially called by several threads at the same time

Pure JavaScript edition [in progress]

Due to the emergence of HTML 5 on all sorts of browser platforms (mobile), the improvement of JavaScript engines such as Chrome V8 and the emergence of Node.js on the server-side, it sounds like a good time to push for a comprehensive Restlet port to JavaScript both client-side (browser and Node.js) and server-side (Node.js), reusing the Restlet API semantics but in clean JavaScript way.

Of course, we already have the GWT edition of Restlet which provides a nice solution, but there seems to be room for a more hypermedia driven/document oriented solution, combining AJAX and UI libraries such as jQuery, Ext JS, YUI to name a few. In Restlet Incubator, we already have a prototype of such port working in both browsers and Node.js on the client-side. See this specifications document for details.

Easier dependency injection

Guice extension

There is already such an extension maturing in the Restlet Incubator that we should try to migrate to the main trunk. Necessary adjustments to the Restlet API should also be made.

Spring extension

We will add support for custom XML schema in Spring, based on our existing custom XML syntax implemented by the Component class. This will also be the opportunity to improve the Spring extension document which is a regular topic for questions. See related issues #614, #638 and #992.

Build process, distributions

Generate snapshots for stable, testing and unstable releases

Add Debian rpm distribution (minor priority)

Automate code check of the android edition

Open source community

Add metrics (downloaded versions, watchers, followers, tickets, etc).

Development mode

Multi-IDE code

The current source code available via the version control system is dedicated to the Eclipse. We should target the other IDEs and propose a structure of the source code that does not depend on a particular IDE. This enforce the usage of Maven structured projects.

Migrate PDE to M2e structured code

Migrate the documentation for the contributors from the current wiki to the target platform : Github.

User documentation

Migrate the documentation of the current wiki

To the Javadocs (sample code, documentation of editions), the Github wiki (developers), the Github pages (tutorial).

Code Quality

Usage of Sonar, checkstyle, findbugs, PMD (see issue #9).

Continuous integration (Jenkins, cf Cloudbees).

Production

Use Google analytics

Version 3.0

New tutorial

So far our user guide documentation has been rather technical, with first steps documents, basic tutorials, edition and extension description and Javadocs. In addition, we are publishing the comprehensive "Restlet in Action" book for users wanting to get a deeper understanding of the framework.

However, we received several feed-back for a better introductory documentation, that would help understand the potential of the technology with a sensible use case, a complete end-to-end example including persistence and UI. This would also give a way to share best practices and illustrate usage scenarios of the technology such as:

• open web API
• cloud migration and portability
• mobile web sites and services
• unification of web sites and web services

Therefore, we want to write a new and in depth tutorial presenting a example comparable to Seam's Hotel Booking one or a RESTful Java PetStore (we already have a prototype based on older 1.1 version).

Restlet Studio

In order to facilitate the usage of the Restlet Framework withing Eclipse IDE, we would like to start providing tooling support such as wizards to facilitate the creation of Restlet applications, filters, resources, etc. See this wiki page for details.

In addition, the core development team will migrate to the latest version of Eclipse Indigo (3.7) as their main IDE development tool, ensuring that no errors and warnings appear with the source code in trunk.

Restlet Search

First reusable and extensible Restlet App offering a complete, embeddable indexing and search engine. Based on Apache Lucene and offering a RESTful and lighter equivalent to Apache Solr.

Support for SPDY

As this protocol defined by Google is gaining more acceptance with its support in Amazon Silk browser and is compatible with HTTP semantics, hence with the Restlet API, we will add support for it by leveraging and extending our internal NIO connector. Mozilla is also adding support for SPDY in Firefox.

There are some good chances that a HTTP/2.0 standardization effort will emerge in the near future, also based on Roy T. Fielding's Waka and the HTTPbis working group that split the HTTP/1.1 specification in several layer, including a separate messaging layer and semantics layer. See this blog post for details on Noelios's vision.

We will also further optimize those NIO connectors (HTTP, SIP and SPDY) by performing a comparison benchmark with other connectors (Jetty, Simple) and further improving the NIO controller loop. We will also facilitate the reporting of statistics on the connector via the ConnetorService, such as the number of active connections, the number of calls per second and so on. Finally, we will attempt to use a single NIO controller to manage several connector instances (client and server sides, several listening addresses, etc.).

Dart edition

Dart is a promising programming language launched by Google in 2011 at the cross-roads of JavaScript and Java that is both statically and dynamically typed. It looks easier to port Restlet to than to pure JavaScript, a bit similar to the porting done for the GWT edition.

Enhanced conneg service

We want to facilitate content negotiation based on other dimensions than representation metadata byenhancing the existing ConnegService added in version 2.1. For example the "account.html.ftl.ie" file could be mapped to the HTML media type, decoded using the FreeMarker template engine and returned only for Internet Explorer. The "vary" HTTP header (Response#dimensions property) should also be updated properly. Example of new dimensions that could be taken into account:

• user agent type (ex: Firefox)
• user agent category (ex: mobile, desktop, etc.)
• user agent version
• user preferences
• IP address and domain name (ex: UI branding, white-label)
• authentication state (ex: anonymous version)
• authorization state (ex: user role)

Enhanced converter service

The current converter service supports the serialization of objects into representations or the deserialization of representations into objects. This works fine and uses a plugin mechanism for extensions such as XStream, Jackson, JAXB, JiBX and a few more. We want to go beyond in 2.1 and support three other scenarios.

Unified bean converter

We currently rely on many extension to support serialization between POJOs and common formats such as JSON (JSON.org, XStream+Jettison, Jackson), XML (XStream, JAXB, JiBX), RDF, GWT, etc. However, those extensions and related libraries tend to have much redundancy and lack integration with REST representations such as metadata and hyperlinks. As Roy T. Fielding reminded in this blog post, REST APIs must be hypermedia-driven, especially on the client-side if you really want to loosely couple web clients with web servers.

We will help Restlet users to easily support conneg over various media types, with a single consistent set of representation annotations and illustrate this support for common media types such as XML, JSON, HTML/Form post, RDF or CSV. See this specifications page for more details.

From representation to representation

This is based on a transformation document (typically a template or skeleton of the result document). An example case is the usage of XSLT to automatically convert a WADL representation or a XStream/JAXB/JiBX XML representation into HTML representations. A mechanism to register or discover the transformation documents should be provided, based on the source and result media types.

From object to representation using a template document

An example is an object returned by a @Get annotated Java method) that needs to be converted into a result representation (for example an HTML document). There are currently two ways provided by the framework to do that via the FreeMarker and Velocity extensions. This idea would be to simplify the usage of those extensions and their TemplateRepresentation classes via the ConverterService.

It would also be useful to be able to select a different template based on a query parameter or any attribute actually, for example to display a read-only HTML document or an HTML form capable of editing the resource.

This would be pluggable so other template mechanisms such as Acceleo (generates text from EMF beans) could be supported. A mechanism to register or discover the transformation documents should be provided (for example based on the qualified class name of the source object in a base directory of templates).

From object to object using a transformation document

Third, the conversion of a source object into a result object should be supported. This could be leveraged by technologies such ATL (transforms source EMF beans into result EMF beans). A mechanism to register or discover the transformation documents should be provided, based on the source and result qualified class names.

Support HTML 5 Server-Sent events

This W3C specification part of HTML 5 is now supported in major web browsers and is RESTful so we should support it directly in the framework. Generally, we should Improve our asynchronous support for use cases such as CouchDB notifications and Twitter live API.

Build, distributions

Add a distribution for the incubated projects (issue #134).

Java JDK evolution

Migrate the source code to the JDK 1.7.

Development mode (IDE)

Migration from Eclipse 2.7 to Eclipse 4.2.

Ease usage of the Restlet framework

Provide Maven archetypes (see issue #463).

Provide sample code using a kind of demos explorer.

Users documentation

Customize Javadocs by edition, customize the javadocs page (logo, etc) leveraging on the features offered by the JDK 1.7.

Restlet server

Migration of the build process on EC2, migration of static files on the Github download area.

Conclusion

For a more detailed and up-to-date roadmap, you can always check this page and browse the listed issues that will be updated to reflect the plan above. If you see a feature you would like to help us with, please jump in and contribute to make it happen sooner.

If you don't have enough time to share, your company can also help us by funding the development of some features. See our co-development offer at Noelios Technologies.

Finally, nothing is written in stone, so please express yourself, we are looking forward to your feed-back!