I already requested a contrib project for Cristal.
This project contains the code of Cristal itself (mostly Typescript and Vue 3 components).
But, Cristal is meant to be connected to various sources (XWiki, Github, file system, …).
And, we currently need to install on XWiki an extension in order for Cristal to interact with it (see the prototype by @ludovichere).
I’d like to request for a contrib project to port the prototype to a more stable place, and be able to release and distribute it.
The proposed name is not that explicit to me (it’s also hard to understand if it’s an xwiki extension for cristal, a cristal extension for xwiki and what it’s about). Also, if it’s an xwiki extension we don’t usually specify “xwiki” in the name (see https://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HChoosingthename), so maybe something like connector-cristal?
Could you explain what you mean by “connector” (ie what this extension is doing) so that maybe we could find a better name?
I agree with Vincent that the naming is not great. My understanding is that it would be the place for a new distribution, so why not distribution-cristal?
No only, that distribution is mainly for testing purpose.
Good point.
Currently, it’s mainly providing a rest endpoint (i.e., /xwiki/rest/cristal/*) returning the content and related resource (e.g., javascript, css) of page on a format that Cristal can process (json or json+ld).
That’s the main reason yes. But indeed I might be able to rework the Jenkins pipeline to have it run maven and node. This would also require a bit of change in the build images, currently we are using the build-node docker image for node (instead of the usual build docker image) which do not have maven installed.
Our use-case has evolved a bit, and on top of having a connector extension for Cristal, we will also need a project to provide shared components between Cristal and XWiki, and at some point a complete Cristal skin.
As such, I would suggest the name cristal-integration.
code to integrate Cristal inside of XWiki or rather code in XWiki to make Cristal work with an XWiki backend
shared UI components that can be reused by Cristal, XWiki and others.
I’d suggest 2 different repos.
Also note that we will want to depend on the shared UI component in XS by default, while the Cristal integration may be optional, at least for a while. In addition I don’t think that they’ll necessarily have the same release cycle.
I don’t think the difference is that big. I understand what you’re saying, but in practice if we have a shared UI component between both Cristal and XWiki it might end up requiring a specific REST API endpoint on XWiki side that would be essential to use it in both Cristal and XWiki.
Also, a user doesn’t need to install all of the extensions provided by a contrib repository, or does he? I might have missed this.
My thoughts on this were that it wouldn’t be a problem to migrate these UI components to the XWiki codebase when they reach maturity, but I guess it might lead to manual upgrade steps I did not consider at the time. Not sure yet how to handle that properly.
For now, we only need the first item (i.e., cristal-integration)
I propose discussing the second point separately. Since it’s going to be a shared library, it could perfectly have a specific name that does not involve Cristal.
A common UI component cannot call a REST endpoint as it wouldn’t be generic. The shared components need to be usable by any project (XWiki or other).
Now if XWiki is missing a REST endpoint it should be added on the XWiki side. Do you have an example of a REST endpoint that would make sense only for Cristal (and that’s not a workaround ofc)? In any case this would go in the Cristal integration repo, and not the shared UI one, which is point 1.
Indeed. You’re right. The only reason to group them together is if they always have the same release cycle.
For example imagine that XWiki requires a new version of the shared block note editor component. This would require a release of the repo containing that component. I don’t see why we would also need to release the Cristal integration at the same time. For me shared component != Cristal integration.
I don’t think this will happen since AFAIU we’ll want to keep Cristal in a different repo than XS since it can be used with a different backend than XWiki. Cristal and the shared component will be moved in the XWiki GH organization, but not in the platform repo. In their own repos with their own release cycle (we will certainly try to sync the releases but there’s no reason to release Cristal at the same time as XWiki, it could be released more often for ex).
The way the endpoints are provided for Cristal are very different from what we do for XWiki currently.
we return data on the rights granted to the user, to be able to adapt the UI client-side (e.g., hide the edit button when the user doesn’t have edit rights)
we return together more data than what is possible with XWiki rest endpoints on a single query (which could be achieved with GraphQL endpoints too, for instance)
I agree, the final goal is to completely remove this Cristal specific integration.
But I’m not sure if we are ready to do this yet, and it will require discussions on the XWIki section of the forum to agree on the best way to do this.
On the other hand, we are currently relying on a bunch of groovy code directly embedded in wiki pages that are not distributed by the extension manager.
So what I propose is to create cristal-integration to have something (temporary) we can easily distribute and maintain.
Then, we can agree to add on the roadmap tasks to gradually migrate things into XWiki Platform and hopefully deprecate quickly the adhoc integration.