PreplanningEngine#notifyChangedTripInformation has as argument Optional<TripInfo>. I am wondering if the hedging against a possibly non-existent TripInfo is truly necessary here. I.e. is there a use case? If I see it correctly, the method can only be called for trips that were already accepted before. Surely, a drt vehicle can break down or other things can happen, but can't we treat them by moving the pickup time to later? As you know, for our uses cases (drt being part of public transit), rejection is not an option anyways, because there is a service requirement. Is it an option for commercial operators, i.e. is it an accepted strategy (worth of scientific investigation) to first accept pre-bookings and then cancel them later?
I just don't want to spend time and effort on corner cases that should not happen in a normally functioning system.
Also, my IDE says that Optional should not be used in method signatures.
The rough idea is:
send a TripInfoRequest to many providers
collect “initial (approximate)” TripInfos from different providers (could be more than 1 per provider)
choose one of the TripInfos (and make a prebooking if booking is required)
at this point the initial offerings will be validated and confirmed by the provider (it may happen that the initial trip info is not valid anymore)
if the trip info is not valid, the agent can (potentially) choose from other trip infos, or re-query the providers
As for rejections (aka. not valid trip infos), there may be several reasons:
all tickets sold out in the meantime (e.g. planes, trains…)
no available vehicles (this is what actually can happen with DRT even if rejections are turned off)
Yes, this should not be an Optional<TripInfo>. Maybe it should even be something more than just a TripInfo (something like a booking confirmation with a pointer to the selected TripInfo??)