While we strictly want to avoid limiting the models that can be visualized and edited via GLSP to be EMF-based models, it certainly has an advantage to use EMF as a framework for representing the runtime SModel on the server. This would ease things like validation, undo/redo support, change notifications, adapters, etc.
In my view, a specific GLSP implementation for a particular model needs to map the arbitrary representation of that model into an SModel at runtime (aka SModelFactory as also the case for some Sprotty examples). This SModel is then the representation on which the GLSP server acts, without knowing or caring where it came from. During the editing process, the GLSP server sends change notifications to the component that originally created the SModel, which in turn maps the changes (or the changed state) back to the original representation. Whether the SModel is now EMF-based or not doesn't interfere with the original model to be anything from POJOs, EMF models, or Xtext-based EMF models.
While we strictly want to avoid limiting the models that can be visualized and edited via GLSP to be EMF-based models, it certainly has an advantage to use EMF as a framework for representing the runtime SModel on the server. This would ease things like validation, undo/redo support, change notifications, adapters, etc.
In my view, a specific GLSP implementation for a particular model needs to map the arbitrary representation of that model into an SModel at runtime (aka
SModelFactoryas also the case for some Sprotty examples). This SModel is then the representation on which the GLSP server acts, without knowing or caring where it came from. During the editing process, the GLSP server sends change notifications to the component that originally created the SModel, which in turn maps the changes (or the changed state) back to the original representation. Whether the SModel is now EMF-based or not doesn't interfere with the original model to be anything from POJOs, EMF models, or Xtext-based EMF models.