I put a proposal into Gemini for a new kind of provider - a "PageState Persistence" provider. I would like to get feedback whether this is a good idea or not. See:
DNN-14357 - Provider model for PageState persistence
This isn't a show-stopping issue, just something that if at some point got added to the core would make a difference.
Here's what it says in the ticket:
Currently DNN natively supports two PageState persistence mechanisms (Page and Memory) and the host user can switch between them in Host Settings.
Historically there have been many problems reported with the Memory option, to the extent that it was at one point removed,then added back with a warning about its use.
However, there is still a great interest in having a (working) server-based mechanism for the large potential performance gains. How to implement this "correctly" is a hot topic in the developer community, and not just in DNN as this is an issue for ASP.NET sites generally.
Because the current implementation is coded into the DNN core, there is not much opportunity for developers to develop their own implementation, and for these solutions to be shared with the community/sold. The public perception of the Memory option is that it is a "broken" feature which should and could be made to work if only the core team would do X, Y or Z.
In my view, implementing a Provider model for PageState persistence would , transform this situation. There would be two built in PageState persistence providers i.e. the current Page and Memory options (or possibly just Page, if Memory is still unreliable), with Page being the default. As with all other providers, changing it would be via extension installer or manually in web.config (the options in Host Settings would be removed). Developers could write their own alternative providers and package them for sharing with the community or as commercial products.
This area might then be perceived as "DNN has a working page-based mechanism, and if you want to pursue a possibly better performing alternative you can try these third-party alternatives".