Yes, it would be non-trivial. The catalog editor uses jgit to access the catalog. It has to clone it into a local repo and it loads it into an in-memory database. Neither of these were designed to be access by multiple users at the same time. For example, when you update the catalog it updates the in-memory database. When you tell it to persist it it converts the database to JSON and commits that to the local repo and then pushes that to the remote repo. Each user would need their own copy of all of this. The way it is now, if two users try to modify the catalog at the same time the first one will win and the second will likely fail with merge conflicts. If they were sharing the same repo and database I wouldn’t know what the end result would be. Modifying the app to have each user have their own repo and in-memory database is possible but could use a lot of memory. In addition, managing the repos on the remote server could be messy.
Ralph > On Oct 15, 2018, at 2:54 PM, Matt Sicker <[email protected]> wrote: > > Is that nontrivial to support? > > On Mon, 15 Oct 2018 at 16:48, Ralph Goers <[email protected]> > wrote: > >> The editor is not designed to be used by multiple users at the same time. >> Setting it up as a remote client will make people think you can do that. >> >> Ralph >> >>> On Oct 15, 2018, at 2:39 PM, Matt Sicker <[email protected]> wrote: >>> >>> Now I know the docs suggest running the catalog editor locally, but how >>> well supported is it to run it remotely? Suppose I have a Kubernetes >>> cluster where my git credentials are available as a secret. Would it make >>> sense to run the catalog editor in the cluster (provided I've >> sufficiently >>> locked down access)? Or is it purely for running on a local machine? >>> >>> -- >>> Matt Sicker <[email protected]> >> >> >> > > -- > Matt Sicker <[email protected]>
