-
Notifications
You must be signed in to change notification settings - Fork 99
Roadmap
Last updated 12/19/2017 by @ElvenMonky
Support of Interfaces.
As of this commit source code provides quite consistent implementation with following notes:
- Does not provide specific object models for different render templates.
Next step can be to publish new version of NuGet package with these changes (presumably 1.6).
There is a quite good port by @tonysurma.
The problem for original library is a bit deeper.
First point is related to AlexaSkillsKit.Net library development environment. Current solution supports VS 2012 IDE. .Net Standard requires at least ".NET Core 1.x SDK" to target .Net Framework, which in turn requires at least VS 2015 (preferably VS 2017 or VS Code) as a development environment. Problem can be solved by having separate project and solution files for 2 versions.
From NuGet perspective we need to provide multi-target NuGet package to allow VS 2012 users to continue to use the library. It looks like .Net Standard NuGet packages support will never be added to VS 2012 And unfortunately, new way to declare NuGet packages in .csproj file does not seem to support multi-targeting and only creates .Net Standard NuGet packages. So, we probably stick to the .nuspec as described here. This also enforces destination files project structure, when preparing NuGet package for publishing.
Alternative approach would be to have separate branch and possibly separate NuGet feed for .Net Standard library version. This however complicates sharing of feature development. We can also consider to drop VS 2012 support for v2.0 release.
Estimated version to support this feature is 2.0. However, there are few more thing to consider to be included in 2.0 release as described in "Extensibility" section below.
One problem with current library implemntation and structure is that it is quite difficult to extend with new requests and interfaces being invented by Amazon. Hot fix for existing interfaces was to inject all new features directly into the core library. However in a long run this is not a best way to go. First let count possible drawbacks of current solution:
- Particular Speechlet might deal only with specific subset of existing interfaces. Some may need only standard requests.
- If new request type arrives Speechlet author have to wait for new library version to be released or fork from source code and reference it directly to make necessary changes.
- No generic certificate, signature and time stamp validation methods are exposed making Skill authors to convert incoming data from their HTTP API formats to System.Net.Http's specific HttpRequestMessage. One good example is "ASP.NET Core Web API"'s HttpContext.
The better solution would be to make core library extensible for new requests, interfaces and .Net REST API libraries and extract all interface or implementation specific code to separate NuGet packages. This will allow 3rd-party authors ability to add their own implementations for new frameworks and interfaces, possibly followed by including those implementations into main NuGet feed.
Here is the brief list of steps to make library extensible:
- Remove request parsing and validation code duplication
- Extract reusable parsing and validation interface (based only on built-in parameter types)
- Refactor
SpeechletRequestEnvelop.FromJsonto allow registering deserializers for specific request types instead of hardcodedswitch-based request type resolution. - Allow interfaces to register their own state within Context object (better then AudioPlayer state is currently handled)
- Allow interfaces to register their own deserialization code for System.Device.Supported Interfaces object
- Allow interfaces to register their own handlers for specific request types. Refactor
Speechlet.DoProcessRequestaccordingly. - Extract existing interfaces into separate project libraries. Provide simplified interface registeration code for library consumers.
- Implement as separate provider libraries support for most common .Net Web Frameworks, primarily Asp.Net Core 1.x/2.x Web API.
The work on this is already started in following fork by @ElvenMonky. Any participation is greatly appreciated.
There are few attempts to ease Speechlet response building process especially for complex responses that include one or more Directives. Just couple of references to notice:
- Default responses by @realares
- Speechlet response builder by @ElvenMonky
Actively growing feature set requires better code coverage by at least Unit Tests. We need to find a resources and spend some time to shape our test plan and create tests for core library functionality.
Existing documentation requires significant update to reflect newly added features and nearest plans if possible.