Elevator Action Requests for door and lamp

[ryandash]

• added ElevatorDoorRequest, ElevatorLampState, ElevatorLampRequest

[withaspirit]

I agree with this in principle, cause Scheduler should be the one telling elevators to do stuff, but I'm also concerned that there's getting to be too many requests

[ryandash]

I agree with this in principle, cause Scheduler should be the one telling elevators to do stuff, but I'm also concerned that there's getting to be too many requests

I am considering just making it 1 new type of request called ElevatorStateRequest and making an enum ElevatorStates to hold all possible elevator states. The problem with doing this is that the elevatorSubsystem will need to perform more checks

[withaspirit]

What's the idea for elevator states? Like, how many would there be?

[ryandash]

What's the idea for elevator states? Like, how many would there be?

A state for each lamp state, door state, and other types of states.

[ryandash]

Keeping them separate is probably a better idea

[withaspirit]

For new files, I think we should be reformatting them with spaces instead of tabs.

[ryandash]

For new files, I think we should be reformatting them with spaces instead of tabs.

Why would you use spaces instead of tabs?

[withaspirit]

This is an aside, I think if we analyzed the requirements to identify every point at which Scheduler would be sending stuff to elevator, it could make things easier for us.

Another aside, but if we had the requestQueue in Scheduler instead, we could just remove requests in the scheduler upon confirmation that elevator arrived to a floor.

[withaspirit]

Maybe scheduler could have something like a HashMap<Integer, ElevatorState / RequestQueue> where elevatorState would have:

• serviceDirection
• currentFloor
• MovementState
• MovementDirection
• Fault
• DoorsState

[ryandash]

This is an aside, I think if we analyzed the requirements to identify every point at which Scheduler would be sending stuff to elevator, it could make things easier for us.

Another aside, but if we had the requestQueue in Scheduler instead, we could just remove requests in the scheduler upon confirmation that elevator arrived to a floor.

I am very confused about what the benefit of having a requestQueue would be in the scheduler. The scheduler is updated with elevator monitors. The scheduler itself does not need to be aware of the elevator's states. The only state that it needs is a state of STUCK for the elevator selection algorithm.

[withaspirit]

I am very confused about what the benefit of having a requestQueue would be in the scheduler. The scheduler is updated with elevator monitors. The scheduler itself does not need to be aware of the elevator's states. The only state that it needs is a state of STUCK for the elevator selection algorithm.

I'm moving this discussion to #184