This outlines some of the changes to be made over time. No particular order though some depend on others.
Change the api to use response objects throughout. No exceptions. Allows for a better networked api.
The public client is read-only and could do all its interactions with elasticsearch. A small amount of work is needed to add more information to ES to enable this. Most interactions are already with ES. There are a few - mostly those related to accounts and calendar suites which still touch the database. The back end needs refactoring into a db + ES version and ES only. Benefits are a much more lightweight client with faster responses and less load on the database.
For this we would do all interactions with ES and connect to and update db only as needed. Use sequence numbers to ensure db and index correctness. Benefits are shorter db interactions - only at point we update. Less complexity in web clients - no need to have conversations stretching across multiple requests. This can build on the work of the previous item. The web client code is already structured ro assume that it will do an explicit update of entities which should facilitate the change.
Move as much as possible out of the current webapps module into the core APi implementation - this potentially allows a more RESTful style of client - possibly using the new jmap style interface being developed.
Use a larger category scheme as the basis for categories. Use SKOS based representation so that they are RDF friendly. Will allow for sub-categorization by event submitters.
Allow for use of external location sources such as geonames. Will allow good locations on external events.
Searches of other entities such as locations. Search for events near a geo-location (requires locations to have geo)
Implement caching of feeder data as a built in feature of the quickstart.
Finish off the deployment process - it's THAT close (is there an emoticon for 2 fingers very close together?) to allowing deployers to just replace the ears from prebuilt ears on the site. No builds required - server can detect an update is available.
If all - or many - required dependencies are deployed as wildfly modules it should reduce the size of the deployment and allow for even quicker startup.
Subset of svci but can be used for web client interactions.
Directory interface to directly interact with grouper for user and admin groups. Allow consumer only approach for external management of groups. Use extra ldap attributes to allow admin groups to be maintained in ldap.
Use kibana to get metrics etc
Update UI to provide a search - possibly based on map. Use tzdist geo feature (being developed)