The primary issue is that users would want to keep their entire set (graphics and configuration data) in the web-based tool. That means:
- would need persistent storage (database) for the data, and for the graphics (potentially large)
- there would need to be some accounts and log in system
- some sets are multi-author, so there would need to be projects
- there would need to be backups
- despite being persistent, it would likely need import/export
- probably users would pretty quickly want undo / history
This makes me wonder if one can write such a system as an add-on to Redmine, which powers dev.openttdcoop.org. That would take care of login, project, version tracking (undo).
Yes... that would be possible. The currently-used web front-end to the repositories, https://kallithea.openttdcoop.org
allows already in principle to edit the repository via the web frontend as well as to upload files to the repositories to logged-in people. It's just that no-one has a login there, as #openttdcoop has no unified identity service, thus it would be yet another service where people would need registering - which would need exactly the same permissions and users as redmin - thus a single sign-on is basically the stumbling stone here. Tieng a build trigger to a commit done there is possible. Thus if one sticks to a pre-defined format, it would likely be not overly compliccated to create such project
Undo is no concern when you have repositories - or you simply reset for e.g. not-logged-in people (but that'd be a pain with graphics to reverted.
Before that (or concurrently, I don't recall), I experimented a bit with an interface to jenkins which at least does the automatic build for you when you upload a zip which contains everything needed to build your grf from (and which follows a certain form of course): https://jenkins.openttdcoop.org/view/De ... load-test/
- but I didn't quite consider that too useful... it still requires you to get everything right and the only thing which could be skipped is the installation of the build tools; thus you'd be uploading megabytes for megabytes for every single typo you do in your code.
I'm actually unsure as to what "the best" interface would look like or should look like... if someone is eager in trying to implement something like that here, I'm happy to be of service.