Modeluri explanation?

[GaryKopp]

As always, I'm a little, strike that -- a lot, confused. Now that I'm looking at the ecore-glsp code I'm drawn to ModelServer itself. Interactions with the model server use a "modelUri" parameter. Does this parameter always point to an external file? I thought model server internalized a given model and then provided APIs for interacting with that, but all the interactions I see in the model server readme include a modelURI parameter naming what seems to be an external file. What am I misunderstanding?

Let me include another question that is just an aspect of the one above. In the readme's "REST API Example" one piece demonstrates a PATCH update with a modelUri of SuperBrewer3000.json. Does such an update physically update the file SuperBrewer3000.json?

And yet another related question, concerning the HTTP endpoint that "gets all available models in the workspace." In the context of this request what constitutes a model? IOW, how does the model server decide that something in the workspace is a model?

[planger]

As always, I'm a little, strike that -- a lot, confused. Now that I'm looking at the ecore-glsp code I'm drawn to ModelServer itself. Interactions with the model server use a "modelUri" parameter. Does this parameter always point to an external file? I thought model server internalized a given model and then provided APIs for interacting with that, but all the interactions I see in the model server readme include a modelURI parameter naming what seems to be an external file. What am I misunderstanding?

A modelURI identifies a model resource, wherever it may come from. It doesn't necessarily need to be a file, in most of the common scenarios however it is a model file that is requested by the client and loaded by the server. Loading one file identified by a URI may implicitly load referenced model files too, but this is encapsulated from the client.
The model server per se isn't initialized with a single model, but it provides an API to give clients access to any number of model instances that conform to the Ecore models (say schema, metamodel).

Let me include another question that is just an aspect of the one above. In the readme's "REST API Example" one piece demonstrates a PATCH update with a modelUri of SuperBrewer3000.json. Does such an update physically update the file SuperBrewer3000.json?

It updates the in-memory representation of the resource. Once the client requests a save, it is physically saved to disk too.

And yet another related question, concerning the HTTP endpoint that "gets all available models in the workspace." In the context of this request what constitutes a model? IOW, how does the model server decide that something in the workspace is a model?

I'd guess this is decided based on the file extension, but I'm not sure. Maybe @ndoschek can answer that?

[GaryKopp]

Many thanks for your answers, Philip. Let me ask a followup. ecore-glsp requests the type schema (ecore.ecore) perhaps multiple times during a session from the model server in https://github.com/eclipse-emfcloud/ecore-glsp/blob/master/client/packages/ecore-property-view/src/browser/property-data-service.ts. Would that not be cached by the model server rather than be re-read from disc on subsequent calls? If so, why did it become necessary in this code, for performance reasons, to hard-code the type schema into the application? Just makes me think it was found to be repetitively read from disc.