Current and future state of the Cristal extension for XWiki

Cristal
1

Hi everyone,

This topic will be for discussing the Cristal extension, that is currently hosted on Cristal / XWiki Experimental APIs for Cristal Wiki Prototype · GitLab

Initially, this extension was a prototype made to easily provide an endpoint for Cristal. It supports:

  • Returning a page (as JSON-LD) including its metadata, HTML rendering (for a given user), and information on whether or not the current user has edit rights on the page,
  • Returning the content of a panel for a given user.

A contrib repository request was made a while ago to port this extension into Java, but it did not reach a consensus.

Now, the Cristal project has come a long way, and we should consider a few things:

So far, we have never used the panel feature. Do we still need it, and if not, should we remove it if we port the extension to Java?

Right now, the only reason we still rely on the extension is that it centralizes several data that we need for a given page: the page and its metadata, the HTML rendering, and edit rights. These can, however, be separated in three different requests:

  • We can get the page from the REST API
  • The HTML render is available through the get action
  • Edit rights can be checked easily by making a HEAD request to the edit action

However, separating what was previously a single request into three could create consistency issues while also increasing response time. It also causes CORS issues because the actions endpoints are not designed to properly answer to pre-flight requests.

Considering all that, we need to think about the best course of action: do we want to keep the extension, considering we only use a part of its features? Do we want to port it into a new, more visible, repository, and if so do we keep the features we don’t use? Do we want to stop using it, and if so, how do we handle the transition? Do we try to improve CORS support on endpoints that are not parts of the REST API, or do we add missing features to the REST API? And should we try to find a way to get all the necessary data in a single request (by, e.g., exposing a GraphQL endpoint)?

Don’t hesitate to bring your feedback on all these points!

2

+1 to not port it as it is currently unused. But we still need to consider that we might need to reintroduce it later when designing the extension.

I would suggest using an actual rest endpoint, as iirc XWiki rest endpoints allow cross origin requests.

+1 to only migrate what we use, as long as we keep in mode known future usecases.

I think it must be a proper contrib extension, following the best practices.
This would also make it much easier to release and distribute it.

So far, I don’t see a clear path out of a dedicated extension, in particular to access to page content and its rights in a single HTTP request.
I don’t think multiplying small requests to access different information about the current page is a good strategy.

I’m not sure why we wouldn’t use the existing REST endpoints feature of XWiki as what’s provided by the prototype is REST API.

I could be interesting to move the extension to graphql later. But

  1. the code is pretty straightforward to move from groovy to Java
  2. we don’t have enough experience with graphql to be sure it’s a good idea, as it will not be beneficial if not applied globally afaik