Hi devs, We’ve been developing XWiki over 10 years now. I’d like to start a discussion about major architecture changes we may want to do in the coming 5 years.
With this discussion I have 2 goals in mind: * Prepare XWiki for the challenges ahead (prevent it from being obsolete, have an architecture that can adapt to changes, etc) * Make XWiki an interesting project to develop on for its developers (interesting technologies, interesting intellectual challenges, etc) Let me start with a few large architecture items I can think about: * Polyglotism for the front end. This is the ability to code the XWiki UI in any language (PHP, Node.js, javascript, native applications, etc). Right now XWiki UIs are coded mostly using Velocity (and a bit of javascript). It would be nice to be more agnostic and to attract non java developers. The core (Server part) could still be in Java but it would be nice that UIs and extensions could be developed in any language. One architecture that could achieve this would be to have a Core Server exposing all operations as REST APIs. This would decouple the Server part from the Client part. It also means having all XWiki API modules offering REST APIs and making it extra easy to add new REST APIs. * Greatly simplify development of XWiki Extensions. There are several directions that I can think of: ** Direction 1: Expose the resources making up an Extension on the file system and let users use their favorite tools to write the content (web IDEs, text editors, etc) ** Direction 2: Develop an IDE in the cloud. Again there are 2 options here: *** Take ownership of the XWiki Web IDE application and push it much further *** Go in the direction of integrating with a well-known cloud IDE such as Eclipse Che/CodeEnvy (with pre-built workspaces, docker VMs and one click deploy to test your extension, direct deployment of extensions to e.x.o, etc). ** Other: In general, make it faster to develop extensions. The advantage of the Cloud IDE or Web IDE is that it removes the burden of setting up the tools on your local machine (maven, java, etc) so someone new to XWiki should be operational under 5 minutes to run the first tutorial. * Promote our SOLR Query Language as the main query language for XWiki and deprecate XWQL/HQL. Goal: make querying independent of the stores (right now we have a single store implemented on a RDBMS but we can imagine in the future moving to another type of store, and even to multiple stores). ** Make it easy for extensions to contribute new SOLR indexes for their needs. ** Once we use only SOLR QL we can then more easily switch to a different database model. We would also need the next Generation XAR format to be able to fully export an XWiki instance (or some part of it) into a XAR and be able to reimport it (right now lots of stuff are not in the XAR such as data found in the permanent directory). * Move towards a container-based approach to install/deploy XWiki (docker, etc). The idea being to start being microservices-friendly. Right now we already have 2 such services in XWiki: external SOLR + office imports with an office server. We need to be able to include those in distributions and add more. It should be easy to develop a new microservice and set it up in XWiki for redistribution. ** It may be interesting to investigate infrastructure frameworks such as kubernetes, apache karaf and the like. The goal being to build systems that are more responsive, resilient, auto-adaptive, elastic (see the reactive manifesto at http://www.reactivemanifesto.org/). ** We could imagine to be able to package our office import micro-services (ie including an office server) as an extension that can be installed and deployed in the XWiki system automatically. Ok that’s already a good start. Let me know if you feel excited by some of those and feel free to add more. Note that the idea here is to brainstorm about large architecture changes. Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
