14 Nov
2016
14 Nov
'16
3:34 p.m.
There is an interesting point Caled did, the one about identifying what we
want to make first. I am not sure we have anywhere on xwiki.org a page that
describes what are the qualities that XWiki has/wants. Is Polyglotism one
of them? Is backwards compatibility an attribute of XWiki? Being a platform
is something that we will always be? Defining our core values as a
community would indeed make the direction selection easier and also would
help new developers see if this is an ecosystem they want to be a part of.
Most of the things you mentioned Vincent are a bit technical, so I'm not
sure I understood them fully, but I cannot say I disagree with anything.
The most interesting domain I would be interested in is the "Polyglotism
for the front end". Also I don't think we will find a solution that would
allow us to write once and then have the code easily updateble. Once every
couple of years we will need to rewrite parts of our code, in order to keep
them up to date. I love our ability to easily integrate any new
framework/language inside XWiki and make it work somehow. This will always
penalize us in terms of consistency of look and behavior or in terms of
performance, but being able to be that extensible and flexible is great (at
least from a developer's perspective).
There is another thread started by Guillaume D about "Bootstrap 3.x.x will
no longer be developed" http://markmail.org/thread/ba5oy3mqsrcp7zpp . Being
a product for such a long period of time, this is the hardest thing to do:
trying to keep up and adapt to new technologies. And adding new stuff is
easy. The hard part is knowing when to let something go. I'm interested in
replacing Velocity with something else as part of our standards and
recommendations, but we will still need to keep the Velocity support for a
long time. And this is a recurring question that we had for PrototypeJS,
that we have now for Bootstrap 3, for Velocity, etc.
I am not sure if we should have boundaries on the number of versions we
support for a certain language or framework, or the time we bundle
something in XWiki. Not sure if we can have like a rule or it's always a
case by case. It would be great to have a tool that analyses how much each
language / framework is used for a particular instance (also inside the
pages) or even for platform. Something like in GitHub, when they say your
product is 92% Java, 4% JavaScript, etc. Then it would be so easy to
justify the need to keep a particular language or framework || or to
understand how hard is to replace something like Velocity.
On Fri, Nov 4, 2016 at 3:34 PM, Vincent Massol <vincent(a)massol.net> wrote:
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.
Since Extensions are the core of our platform, I agree that simplifying the
development of them would help our users create them. This and a powerful
store that allows findability of this contributed extensions. Regarding
Direction 1 and 2, I don't think they are exclusive. I always liked that
for Skins for example you have the 2 ways to create them: in pages and on
the file system. Each developer has it's preferences or access restrictions
when both ways are needed.
* 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.
At XWiki we always were ambitious in terms of the things we want to
achieve, even though we are not that many, we always dreamt big. This was
always a blessing and a curse (dramatic music :) ).
Thanks Vincent for this thread,
Caty
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs