Support for multiple clients

[yannisgu]

I could not find any information on the online help, if geco supports multiple clients or not. If I start geco on different clients and opening the same stage on every client through a shared folder, will this work?

If no, what work would be needed to solve this?

[sdenier]

Short answer:

• no, Geco does not support multiple clients on the same stage
• don't use a shared folder with multiple clients, each client manages its own set of data in memory and they will overwrite each other data on disk!

Long answer: Geco was designed for small events running on a single computer. It has a in-memory database (kind of) and periodically snapshots the database in a file disk (with backup). Introducing some kind of sharing between multiple clients would be quite difficult as it requires reengineering the core, and probably review some architectural decision.

Of course, I have toyed with the idea of providing this capability, but there is no clear path on how to do it (apart from restarting from scratch) and no actual plan:

• I would like to use a simple lightweight tool/library to enable such sharing - without causing too much trouble to the current design - but I have a limited knowledge of the Java ecosystem, and it is difficult to define the requirements
• my "ideal" solution would be to implement some kind of "event sourcing" system, as it is versatile and would fit better some usage patterns of Geco - but it is quite a difficult task

One practical path suggested by a friend would be to first develop/use an embedded/lighweight database+web server:

• it would be used to produce/publish data by other clients (live results…)
• it would not replace the existing persistence system at first

[yannisgu]

Hmm :(

Maybe some thouths: I have looked a bit in the coude and have seen that you have this "registry" classes for data access. So this could work without big refactoring. You could implement a HTTP API with out-of-the-box Java class httpServer or Jetty. This API should implement all methos from the repository class (e.g. POST /addRunnerData and then the RunnerRaceData as POST-Body). This Server can be started by the user with a new "Server" button. A popup or so opens with IP and Port (Random free port).

On a other client in the same network, when starting geco, a new option should be there "Open stage from server". Here user can specify IP and port from the server. When this option is choosen, not the current "Registry" class is used, but a new "RemoteRegistry", which sends foreach action a HTTP request to the server.

Sure, this isn't done in 1-2 hours but I am pretty sure this would work without really big refactoring.

[sdenier]

That's an interesting solution. It would require further thinking, like update strategy for the client (polling the server? Versioning data to retrieve only latest changes?) and server strategy to handle update conflicts with clients. But why not? It is not a top priority for me though, so feel free to experiment and play around.