-
Notifications
You must be signed in to change notification settings - Fork 48
Vision Roadmap
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.
- Add more transport (cross platform) options
- Cross platform WCF Soap (working prof of concept exist at https://github.com/Daniel-Svensson/OpenRiaPlayground/tree/master/HttpClient)
- Cross platform HttpClient based transport (working prof of concept exist at https://github.com/Daniel-Svensson/OpenRiaPlayground/tree/master/HttpClient)
- 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
- Improved EntityRef with FK based lookup in O(1) instead of O(n)
- 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
- An (untested) implementation exists (https://github.com/Daniel-Svensson/OpenRiaServices-1/tree/feature/entity_ref)
- Expose more internal types
- For relection: MetaType and MetaMember
- Entity visitors ?
- Look into client side caching status (OutputCache support)
- Extensibility
- Consider allowing access to server headers (or just add hints to documentation)
- Update supported target frameworks
- Add netstandard2.0 target
- Look into if netstandard 1.3 should remain
- Reconsider Silverlight support (intends to include it in next update
- 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
- 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 library or any other standard for query serialization/deserialization
- Consider shipping SOAP endpoint by default
- Replace synchronous Invoke, Query, Submit with Task based "async" methods
- Required to update Hosting (WCF) for true async invoke (for better perf)
- Multitarget net4x and netstandard
- NEW asp.net "MVC"/owin hosting with netsdandard 2.0 support
Look into using asp.net MVC hosting (DomainController project) for DomainService
-
- Anything wcf specific should be removed from server project
- Release the "DomainController project as a new Hosting option
- asp.net Core hosting (long term goal)
- add asp.net core hosting of services
- Add benchmarks for server operations to Benchmarks repository
- Look into simplifying configuration via code
- Look into default support for dependency injection ( https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection)
- Stop with dual release signed/unsigned (only keep signed)
- Depreciate .signed. nuget packages and keep all assemblies signed
- This will make mainanance, ci and testing a lot easier
- 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
- Use VS 2017 for building all projects
- The "hard part" of building Silverlight projects is already solved, what remains is to get CI builds working (VSTS build requires adding script for Silverlight SDK installation as part of build)
- 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
- Client
- Test
- Client
- Web
- Framework/Source
- Documentation
- Look into possibility of getting documentation from MSDN and updating it
- Add more documentation for new features
- Add Getting started project
- Add samples repository
- Silverlight sample
- WPF sample
- Silverlight+WPF with portable library
- Xamarin mobile sample
- Release updated tooling
- Add all code generation settings to tooling window
- Add official VS2017 support
- Update nuget packages referenced by samples / items
- Setup storage for large files required for testing