This is the current roadmap for open RIA Services project. Development is split into three main branches which are numbered as 4.3, 5.0, and 6.0. We are starting at 4.3 as the current closed source WCF RIA Services has a 4.2 version number.

Open RIA Services 4.3

4.3 will be the initial open source release of Open RIA Services. Here we will fix bugs, add M2M support, change a bunch of internal code to public, and other things which do not break backwards compatibility. The 4.x branch of Open RIA Services will be maintained at least as long as Silverlight itself is supported.

Open RIA Services 5.0

The version 5 branch of Open RIA Services will be where cross-platform work will happen. Supporting the same API across all platforms is more important than maintaining the current Silverlight API as-is. Accordingly, there may be breaking changes within the Silverlight client and/or server parts of Open RIA Services to create a consistent API. If you want to contribute breaking changes to Open RIA Services then the 5 branch is where you will want to be.

Open RIA Services 6.0

The 6 branch is targeted to be released along with whatever Visual Studio release includes the full Roslyn compiler. The focus of the 6 branch will be on integrating Roslyn into Open RIA Services where it makes sense. For example, Roslyn will enable client side POCO object to be used as entities instead of the current code generated entities which inherit from Entity.

Misc.

There are some things that will happen outside of the branches. For example, the various fully implemented DomainServices (DbDomainService, LinqToEntitiesDomainService, LinqToSqlDomainServices) and anything else that was part of the RIA Services Toolkit can be compiled against the original WCF RIA Services dlls. For example, one of the first things we will do is release EF 6 support for WCF RIA Services.

The schedule

We are not far enough along to have a schedule in place yet.

4.3 will be the initial open source release of Open RIA Services. Here we will fix bugs, add M2M support, change a bunch of internal code to public, and other things which do not break backwards compatibility.

What is it

 Features

Compiled against Silverlight 5

The original SP2 release of WCF RIA Services was compiled using Silverlight 4 to maintain backwards compatibility. 4.3 will be compiled using Silverlight 5.

M2M support

Using the M2M support currently provided in M2M4RIA on Codeplex, add native M2M support into Open RIA Services itself.

Change Notification

One of the long standing requests is the ability for server side changes to bubble up to the clients. This will be implemented using SignalR but alternate methods can be plugged in.

Fluent-API based metadata (to replace buddy classes)

 Open RIA Services will favor fluent metadata over ugly buddies.

NHibernate support

A real NHibernateDomainService would be a great addition to Open RIA Services. The big ticket item that needs to be created is the NHibernateDescriptionProvider.

Indexed EntitySets with EntityCollection/EntityRef support

Open RIA Services is currently tuned for small to medium size entity caches. To better support larger cache sized the EntitySets need to have index support and the EntityCollection/EntityRef need to be modified to support those caches.

Server side updates during SaveChanges

Currently, if the server modifies entities that are not in the ChangeSet there is no way to send those changes back to the client during the SaveChanges. As long as this feature can be added without breaking changes it will be in this branch.

Bug Fixes

Primary/Foreign key behavior for new entities where key exists

The EntityRef and EntityCollection change their behavior when entities are in New state to accommodate server generated keys. In situations where entities do have primary keys while they are in new state, for example when a client-side only key strategy is used like counting down from -1 or when GUIDs are used, the normal behavior should be used instead. This may be a breaking change that needs to move to the 5.0 branch.

Client-side only properties are reset to null after a submit or load refresh

 This is an annoying bug for programmers who want to extend the client side entities.

Server side IValidatableObject support doesn't work if no validation attributes exist

 If you have a server side IValidatableObject which has no other validation attributes attached to it no validation will be performed server side.

What is it

The version 5 branch of Open RIA Services will be where cross-platform work will happen. There will be breaking changes in the 5 branch as large sections of Open RIA Services will be redesigned. If you want to contribute breaking changes to oPEN RIA Services then the 5 branch is where you will want to be.

Features

Multi-Client support (.NET/WinRT)

Support for all .NET platforms and WinRT. Includes Windows Forms, WPF, WinRT XAML, , MonoTouch, Mono for Android, and generic .NET

Multi-Client support (JavaScript/JQuery)

Planning on support BreezeJS

mOVE FROM wcf TO web api

The DomainService will be replaced with a RESTful DomainController.

What is it

The 6 branch is targeted to be released along with whatever Visual Studio release has the full Roslyn compiler. The focus of the 6 branch will be on integrating Roslyn into Open RIA Services where it makes sense. For example, Roslyn will enable client side POCO object to be used as entities instead of the current code generated entities which inherit from Entity.

Features

Support client side POCO objects

All of the reasons why people want POCO objects on the server also applies to the client, however until Roslyn support client side POCO objects just isn't going to work very well. That will change with Roslyn.

Populating DomainService CRUD with Roslyn (Experimental)

Imagine this. In Visual Studio you create a new class.

public MyDomainService : DbDomainService<MyContext>
{
    protected override OnSetupDomainService //Note: This doesn't actually exist
     {
        this.Crud.Add<Entity1>();
        this.Crud.Add<Entity2>();
        this.Crud.Add<Entity3>();
    }
}

What we are looking at is a possible design for adding automatic CRUD generation to the DomainService. This would be useful when first getting an application setup but you wouldn't want to go to production this way. So, using Roslyn, we would write a Code Issue that would find these, generate a warning at compilation, and then put a squiggly line under each line. Here is the really interesting bit though, if you right click on the squiggly then using Roslyn we can automate the deletion of the autogenerate line and add the real CRUD code into the DomainService. Considering that you could have a this.Crud.AddAll() that generates CRUD for the entire DbContext I think something like this would be a good way to create DomainServices while getting rid of the current Domain Service Wizard which over time has turned out to be very brittle.

Performance

Advanced caching
MonoX administrators can fine-tune the caching system on both page and Web part-level to reduce the access time and increase application responsiveness.

Viewstate optimization
MonoX can completely remove the contents of the ViewState hidden form field. It practically means that your page will be much "lighter" in terms of size and load times, as ViewState hidden field can hold tens of kilobytes of data even in moderately complex applications. All this is possible without loosing any of the ViewState-related functionality.

HTTP compression
Each portal page or related resource can be compressed on the fly, reducing the impact on the bandwidth and page load times.

High-performance, flexible data layer
MonoX utilizes LLBLGen, a powerful object-relational engine that generates highly optimized, robust and scalable database-related code.

Interoperability

Integration with third-party modules and applications
An additional benefit of the provider model used in MonoX is that all ASP.NET applications that use it can be easily integrated with MonoX. Integrating excellent third-party applications like BlogEngine.Net and YetAnotherForum.NET is only a matter of few configuration changes in the Web.config files of these applications (full examples can be downloaded from the support site).

RSS
Administrators without technical experience can easily set up both RSS providers and consumers in MonoX and enable it to exchange information with external applications.

Licensing and Support

Licensing
MonoX is totally free for both commercial and non-commercial usage scenarios. You pay only if you need framework's source code or a dedicated priority support contract. More details can be found at our licensing page.

Tradition
First commercial release of MonoX was released in 2004. It introduced drag and drop and visual configuration features that are now accepted in the Microsoft's official Web part framework. It was voted as a runner-up in the prestigious asp.netPRO Reader's Choice Awards.

Deployed portals
MonoX powers dozens of portals and similar Web applications around the world. It has served as a foundation for custom-built distance learning, eGovernment, eCommerce, document management, knowledge management, human resource management and other types of applications.