Vision Roadmap

Open Ria Services - Roadmap/Vision

The below areas are areas that are identified as extra interesting for future development. The different points are not prioritized and none of them are promised to ever be implemented. In general most development is focused on small investments to unlock easy to reach but inpactful features. It is most about evolution and not revolution. Apart from the features below, performance improvements are always interesting.

This list contains areas where community investment is extra appreciated and contains issues of varying size. If you are interested in developing a feature, please open an issue if none exist in order to start an discussion so help and additional information/hints can be provided.

https://github.com/OpenRIAServices/OpenRiaServices/issues/127 can be used for feedback and other discussions.

High impact

• Update Documentation
  • Getting started
  • Update "/docs" to reflect changes since WCF RIA Services codebase (async, Task etc)
• Add Samples
• Built in support for Dependency Injection
• EF core support (3.1 might be a good start since it support .Net Framework)
• Net core support
  • Make sure codegen works if server side is netstandard/netcode (with portable pdb support)
  • Hosting on top op "asp net core" (endpoints) or corewcf

Client

• Look into Controls package and se what can be useful for other targets
  • Primary WPF / desktop
• Look into Silverlight.MVVM package and se what can be useful for other targets
  • Primary WPF / desktop
• Look into moving ComboBox project into controls project
• Improved EntityRef with FK based lookup in O(1) instead of O(n) ( https://github.com/OpenRIAServices/OpenRiaServices/issues/6)
  • An (untested) implementation exists (https://github.com/Daniel-Svensson/OpenRiaServices-1/tree/feature/entity_ref)
    • needs to consolidare code shared with normal EntityRef to reduce code duplication
    • Add tests for both kinds
    • Update codegen to use new type
• Look into client side caching status (OutputCache support)
• Add more transport (cross platform) options
  • standard wcf binary endpoint (cross platform, use same implementation as for soap but with other binding settings)
  • Cross platform HttpClient based transport (working prof of concept exist at https://github.com/Daniel-Svensson/OpenRiaPlayground/tree/master/HttpClient)
  • Other transport based on messagepack or grpc
• Structural chagens
  • Split OpenRiaServices…Client.Web into .Wcf assembly and "web" ("binary endpoint"
  • Consider "transports" (DomainClientFactory) implementations from "Client.Core" nuget
    • Consider separate nuget for wcf rest transport
• Extensibility
  • Consider allowing access to server headers (or just add hints to documentation)
• Investigations (long term)
  • Look into using EF.core for change tracking etc instead of current approach which mimics the "ObjectContext" approach popular in EF 4 and EF 5.
  • Look into using odata/graphql library or any other standard for query serialization/deserialization

Server

• net5+ support
  • codegen update, should also allow portable pdb support and allow sdk based projects to be used on server side
  • hosting support
• add built in support for enitiyframeworkcore
• asp.net Core hosting (long term goal)
  • add asp.net core hosting of services
• Consider shipping SOAP endpoint by default
• Add benchmarks for server operations to Benchmarks repository
• Look into simplifying configuration via code
  • Is https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/options a
• Look into default support for dependency injection ( https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection)

Infrastructure/Other

• Reconsider nuget package naming

  • Client packades should use "OpenRiaServices.Client.*"
  • Server packades should use "OpenRiaServices.Server.*"
  • Should "transports" have own "namespaces"?
    • Client.Transports.Wcf or Client. Wcf

• Reorganize folder structure This should allow flattening the hierarcy as well as make it easier to use shared settings in the form of Directory.props and .targets Since VS 2017 support multitargeting no separate folders are required for Silverlight/desktop etc. Should we have a "Transports" folder under client with Wcf, Web (binary), BinaryHttpClient

• • Framework/Source
    • Client
      • Client (OpenRiasServices.DomainServices.Client)
      • Web/WCf? (OpenRiasServices.DomainServices.Client.Web)
      • Controls
      • MVVM? ..
    • Server
      • Server
      • Hosting
  • Tooling (? Maybe separate repro)
  • Test
    • Client
    • Web

• Documentation

  • Look into possibility of getting documentation from MSDN and updating it
  • Add more documentation for new features
  • Add Getting started project

• Release updated tooling

  • Update nuget packages referenced by samples / items