Open t2gran opened 1 month ago
I have now ported most of the suggestions in PR #6130, but a few things reminds:
modules
directory - most of the directories at root level are modules - not all are Java/maven modules, but still. I do not see a reason to group the Java Maven modules under modules
.
With everything in one module it is difficult and time-consuming to enforce the modularity. By breking OTP into modules it will be easier to understand where the boundaries are and they can be enforced in maven dependency - not manually.
This will also allow us to set different quality assurance requeierments for each model. We can for example only allow the core team of developers to change the most important part of the code.
This will also mak it possible to divide OTP into more then one runtime (process) later or swap out part of OTP. There has been a few request for using other street routers - this is probably a difficult task, but should be easier if there is a clear boundary around the street routing. For example, the internal state of AStar is today leaked outside of AStar when returning the result.
A good starting point would be:
otp-lang
-- Common set of scalars and utility methodsapplication
-- OTP Main, configuration(otp/build/router), putting it together - avoid business logic here.raptor
-- Raptor implementationtransit
-- With sub-modules (packages) forsite
,network
andtimetable
. In addition there should be services for query and updating data. Support for applying real-time updates should be here.street-graph
-- AStar and the street graph implementationgraph-builder
-- static data import, sub modules forosm
,elevation
,netex
,gtfs
++sandbox
-- Today there is not a clear boarder between the sandbox modules and the core. There are dependencies going both ways - this would need to be fixed.updaters
apis
This overview is incomplete, the details must be worked when doing this.
Here is an overveiew of what I think could be the target: