MDS Agency and Provider Unification

[schnuerle]

During this week's MDS working group meeting, the idea of merging Agency and Provider together came up. The idea is that maybe it's time in the next major release (2.0) to 'merge' them somehow, but it's not clear how that would work, if it's a good idea, and what it would impact.

We decided to create this discussion area to allow people to share their thoughts, pros and cons on the idea.

Some points to consider:

1. API naming reconciliation work was done for MDS 1.0.0
2. There are more top level APIs that connect or impact both Agency and Provider
3. There is a proposal to make a version of trips in Agency
4. The General Information (common area) of MDS is growing
5. A difference is Agency is push and Provider is pull
6. A difference is who is hosting Agency feeds (agencies) and Provider feeds (providers)
7. Authentication and feed validity becomes simpler for cities with Agency since providers are responsible for sending data
8. Agency was meant for more real time, and Provider was meant for historic, though Provider does have RT endpoints now like events and vehicles. Does this distinction need to be made clear or is it less important now?

We welcome your thoughts on what is sure to be a long, detailed, and complex discussion!

[quicklywilliam]

I brought this topic up again today in the context of 2.0 and New Modes in particular. The workgroup seemed to agree that the divergence between Agency and Provider is more a historical artifact than a design choice, but there is understandable hesitation to take on such a big task in the 2.0 timeframe. My concern is that when we are adding new modes, we'll be bringing (hopefully!) a lot of new implementations of MDS on both the city and operator side. And from our experience with MDS 1.0, it's going to be very hard to do this convergence work once those implementations are in production.

What I'd like to explore is whether there is an approach that allows us to have a unified framework for all of the different MDS endpoints without requiring new or existing implementations to adopt them all (ie forcing anyone to adopt agency or provider). I think we already have laid the groundwork for this with the MDS Requirements endpoint. Requirements gives cities the ability to say which parts of MDS they need. The only remaining work is to clarify and distinguish what the different parts of MDS are designed to do.

To kick off the discussion, here's a quick sketch of how we could begin to clarify this:

• The status endpoints are designed for report-driven regulation. Cities should use this when they need to periodically assess compliances, fees and performance of their program.

• The events (aka Agency) endpoints are designed for realtime-regulation (“air traffic control”). Cities should use this when they need to control the behavior of vehicles in realtime. Note that cities adopting events may also choose to use status as a useful fallback or validation mechanism. Cities might also choose to start more modestly with periodic regulation using status and aspire to realtime using events later. Hence, the two should be designed to work together.

• The vehicles endpoints are designed to give a quick, easy realtime view of the world. Cities should use this when they need a simple way to see what is going on right now. For example, vehicles can help cities respond to a complaint about an individual vehicle or diagnose a system-level problem. Cities may also use vehicles as a useful fallback or validation mechanism for status and/or events (ie to address the "drifting world view" problem).

• The trips endpoint isn't for regulation at all, but rather for the planning & analysis of route data. Here again, cities may also use trips as a useful fallback or validation mechanism for status and/or events.

[schnuerle]

Locked in favor of new Issue #759