Vehicles should embed a list of `next_stations`.

[faultyserver]

Rather than just having one, this allows a vehicle to know where it is going further in advance than just having one station does. The advantages of this lie mainly in clients that want to do predictions.

For example, a client wants to show the route that a vehicle is traveling on. It can get the full list of stations by subscribing to the route object from the identifier that the vehicle provides, and simplify this to a loop with conditional stations (e.g., stations that are only visited after 5pm). To know if a conditional station should be displayed as active, rather than relying on currently-unavailable schedule information, the client could read the upcoming stations and see if that conditional station is being approached.

Having multiple next stations in this example allows the client to update earlier, making the switch less obvious and less confusing to the user (it will likely not be where they are looking). If only one next station was provided, the client would not be able to update until the vehicle was already on its way to the conditional station, which would cause a jump in state from the old path to the new.

Implementation wise, this will be a bit awkward, but can be handled during serialization of Vehicles.

[faultyserver]

To implement this, serialization of a Vehicle would have to look at the route that it belongs to, which is awkward.

With that, here's a question: Would the implementation of Timetable from #15 affect the necessity of this in any way? If Timetable is offering schedule RPCs, could it not also offer a next_n_stations procedure that takes a vehicle object and returns the next n stations it will pass through?

Better yet, could Timetable be responsible for determining the current "active loop" for a Route, and provide it through agency.active_loop_for_route(<route>) or similar?

This wouldn't be a replacement for stations and associated_objects[Shark::Station] on a Route, but rather a supplement that eliminates the need for this change to vehicle.next_station.

[elliottwilliams]

Absolutely. Timetable internally has to know the exact position a vehicle is on its route's itinerary (the "unrolled" list of stations), so it should be able to forward this information onward.

The CanonicalRoute calculation (which, I think, is what you mean by "active loop") is being done locally on Proper as of https://github.com/propershark/proper/commit/3325f6ed8a55d50ca6178adb65c8ce3361a06d37. From my perspective, it's really a UI affordance, and it's reasonable easy to compute given a route itinerary, so I'm content keeping the backend services unaware of anything other than the itinerary (and, thus, associated stations).

So I propose that to solve this, Timetable publishes an RPC like agency.itinerary_position_for_vehicle(<vehicle>) which returns a number.

[faultyserver]

Sounds good. I'll close this issue, then, and label it as delegated for when we start working on Timetable.