Skip to content

Vision Roadmap

Jump to bottom
Daniel Svensson edited this page Nov 14, 2023 · 21 revisions

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/discussions/277 can be used for feedback and other discussions.

High impact

  • Improve Asp.net Core hosting
    • See project readme for details
  • Update Documentation
    • Make sure we have a good bare bones "Getting started" section with details to add Open Ria Services to a solution manually. (Add nuget x on server, add domain service, add nuget y on client, setup link, setup DomainClientFactory and call service)
      • There is some documentation för Asp.Net Core hosting (which probably should be part of main Readme and documentation)
    • Update "/docs" to reflect changes since WCF RIA Services codebase
      • async/Task methods
      • new namespaces
      • new supported frameworks (remove silverlight) and update mentioned "dependencies" (we should not have old VisualStudio versions EF4 or similar)
    • Add new/missing content - for example from wiki or link to good blog services
  • Add Samples

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
    • Partially done: (EntityQuery has been moved to Client projekt)

  • 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)

  • Look into client side caching status (OutputCache support)

    • Add sample or documentation? (use HttpClient and CacheCow for client side support)

  • Add more transport (cross platform) options

    • Other transport based on messagepack or grpc

  • Structural changes

    • Consider separate nuget for wcf rest transport The WCF based OpenRiaServices.Client.Web should be it's own nuget and named "OpenRiaServices.Client.DomainClients.Wcf" or similar

  • Extensibility

  • Investigations (long term)

    • Trimming (and in the extension AOT) support
      • Is it enough to annotate "T" of EntitySet on the Client with dynamic access to properties (and methods for entity actions) =
      • Server probably needs annotation of AddDomainService (in setup) as well as maybe a generator or similar to emit "dynamic access" attributes on all entity (and complex) types exposed by th domainservice
    • 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

  • Improve Asp.net Core hosting
    • See project readme for details
  • Add benchmarks for server operations to Benchmarks repository

Infrastructure/Other

  • Remove old "#if SILVERLIGHT" (search for silverlight in code base)

  • Look at generating API documentation to use in documentation

  • Reconsider nuget package naming

    • Client packades should use "OpenRiaServices.Client.*"
      • consider "renaming" current "OpenRiaServices.Client" nuget to "OpenRiaServices.Client.All" so OpenRiaServices.Client can be used for other things
    • Server packades should use "OpenRiaServices.Server.*"
    • Should "transports" have own "namespaces"?
      • OpenRiaServices.Client.DomainClients such as for Http client

  • Release updated tooling (Visual Studio Extension for VS2022)

    • Update nuget packages referenced by samples / items

  • Documentation

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

  • should we unlist old packages from nuget ("Signed" nuget versions)

  • 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
Clone this wiki locally