I have been thinking about my definitions of routes & profiles for Conductor 2 and I am not convinced they will be useful as such for Randall.

I am interested in two kind of routes:

• “Linear simple” routes: typical circuit loop with ABS-type block guards. There are mostly linear and simple means they don’t have complex rules. There still could be customizations: different speeds for different blocks, specific customizations such as grade crossing horns, etc. Some of these may depend on an engine number (especially sound F functions).
• “Dedicated Shuttle” routes: this is mostly what we have at Randall right now where routes are a mix of generic block mapping conditions and carefully dedicated to specific engines.

The problem lies in the Randall configuration, which is actually the first priority. The hope was to create “generic” routes with customizations applied only in the train profile. The hope is to be able to introduce enough variables to make a route configurable. The problem I see is that it would be hard to update a route and make sure all new conditions are mapped to previous train profiles. Which means in practice re-using train profiles will require a fairly substantial amount of work. I’d also expect a fair number of exceptions to be made in the route-dedicated programming based on the train number.

Here’s an idea: routes define expected variables and profiles define these variables. These variables can also be lambda functions. Basically have a “profile.data” map of key/values. The route should define all the expected key names. When a profile is associated with the route, we can double check that all the keys are defined by the profile and have a value of the expected type.

Something like that. The “vars” string can incorporate the type using a simple colon-letter syntax with 3 simple data types: int/long, string, function. The whole “profile” block can be treated as a map itself but then we lose some of the advantages of groovy type verification.