InitialArchitecturePlans
This document is from the kickoff meeting of the project. It does not necessarily reflect the current architecture.
We began with extensive discussion and diagramming of the system architectures of FivePoints, Graphserver, and OneBusAway, as well as a high-level overview of TriMet's existing system. The developers all spoke to the relative strengths and weaknesses of their projects, both technical and otherwise. We then iterated through a couple designs for how an ideal trip planner would be built, focusing on the requirements that had been outlined previously during the workshop. Finally, we discussed which pieces of the various projects made the most sense to use and where they fit into our new system diagram.
-
The graph manager and router server will be taken largely from Graphserver, as this is the area where Graphserver is the most robust and modular.
-
The narrative engine, which is tied to the GM/RS in Graphserver, will be made more modular, and ideas from FivePoints and OneBusAway will be used to improve it.
-
The admin user interface from FivePoints will be used.
-
The public UI will come in part from FivePoints (and possibly some of TriMet's). This could be factored out into a collection of JavaScript widgets, perhaps as an extension of GeoExt (e.g., as "GeoExt Transit"). (See tickets #8 and #9.)
Throughout our work several technical discussions began which it quickly became obvious we could not resolve in the brief period of time we had available. We decided to temporarily table those discussions and pick them up again on the mailing list. These included:
-
The resource layer. What should its interface be? Should this be a registry, a relational database, or something else?
-
Design of the API(s). What, exactly, needs to be supported and how should it be exposed? (See ticket #4.)