The database needs to be shared between multiple actors: several teams of multiple people working in different companies. For instance, a team may be working on a single project such as a new railway or a large timetable change. Another example would be multiple freight companies requesting new routes.
Additionally, the UI contains complicated elements such as custom maps with the railway network and custom graphs to visualize trains. There is a large ecosystem to implement this kind of stuff via Web technologies. A webapp also removes the need to distribute an installable binary on many different platforms (some may be quite restricted due to company policies) and many different machines (there are many users, see above).
Note that the system uses a client-server architecture but isn't really distributed.
> Note that the system uses a client-server architecture but isn't really distributed.
Yeah, I kind of agree. The thing is, it's orchestrating multiple containers to do the job. I can't figure out why you couldn't just have one container.
Part of the answer is that some of these services need to be scaled horizontally to be able to handle a significant number of users (e.g. tile servers, the core server), another part of the answer is architectural constraints (e.g. the core server needs to keep quite a bit of per-infrastructure data in RAM).
(Of course, it's completely possible to build a single container which runs all of the services in parallel, but then monitoring/scaling/availability/etc are more difficult to handle.)
> (Of course, it's completely possible to build a single container which runs all of the services in parallel, but then monitoring/scaling/availability/etc are more difficult to handle.)
Having done both, I'm always surprised when people say that it is more difficult to handle running N-copies of the same container than a heterogeneous set of containers. Sure, at really large scale you can glean efficiencies from it (which is why one might do it), but there's a lot of complexity that comes with that.
Yeah, I read it. It says: "It is a multi-service architecture where several software components interact with each other. This choice was made to ensure the modularity of the code and to guarantee the exploitability of certain OSRD services by external applications"
Modularity of code is a common explanation for using a multi-service architecture, but it's not a particularly strong one (services are just one way of modularizing code). In terms of OSRD services being accessed by external applications, it doesn't seem like that would work particularly well, given the coupling between the pieces. The only pieces that would make any sense to me for outside applications to directly in would be the PostgreSQL database... and if that were the plan, I'd just host the whole thing in PostgreSQL.
If you read deeper, you'd find out that for example the simulation engine is a separate (older?) system written in Java that does have an API but does not implement other components like designing the railroad system etc.
Shouldn't be too hard, the tool is designed to be intuitive. That said, it may not be obvious how to use the planning part of the tool if you're not familiar with trains.
The README contains instructions to start OSRD with docker-compose, if you want to try it out. Would be nice to have a public demo instance for sure!
There is extensive discussion about adapters in the bug report thread, it seems that some adapters do actually support HDMI 2.1 features, but it depends on their chipset and firmware version. I got a CableMatters one that seems to work, to the best of my ability to test without my TV having a diagnostic panel to show info about the signal it’s receiving.
There's no good way around that unfortunately. The proxy could build in an OAuth client for the major providers, but it's unlikely that this would be trusted by default without significant effort being put into review processes.
As the readme explains, there's nothing to stop you using the existing OAuth client details from another source (such as the many already trusted open source email clients that exist).
Yes. I'd argue the problem is not on the project's side, it's on the Google side (they have ridiculously high requirements for registering OAuth clients for IMAP/SMTP use, especially for a small open-source project).
The provider might notice that their key is being used in an unauthorized way and terminate your account, prosecute you for computer fraud and abuse, etc.
I think this is the only assured way to interop, as I expect Google may try to kill other competing apps (specially in mobile) that does not capture user data or generate data points for its ads.
I wonder if any intentional limitation here should not trigger some of the EU Digital Services Act provisions for interoperability ... in this list [1] I see Google Play, Maps, and Shopping but not GMail!
https://github.com/emersion/hydroxide/pull/282