Greg Latuszek

# Possible solutions **Generic assumption** in searching for solution: we don't want to overcomplicate State Machine (we will use SM abbreviation) of existing devices. Analized solutions: 1. Interactive command injecting...

# Decision Selecting solution 3 as most beneficial even if it requires refactoring code of moler devices SM.

## Required changes in moler devices SM Majority of changes will happen inside **moler/device/textualdevice.py** ### self.current_state It is property of `TextualDevice`. If we jump into sub-SM it should return state...

### Prompt observers They will work as they are. We will not add nested SM prompts (like `OpenSsl>`) into prompt observers of hosting SM. Old responsibility remains - host SM...

## Handling newlines If we jump between states of current moler device it checks what type of newline is defined per state. Since it may happen then local console has...

## `_collect_observer_for_state()`, `_collect_cmd_for_state()`, `_collect_event_for_state()` and related **NO CHANGE NEEDED** These methods return command/event names available for given state - so, they return dict. Names are fully qualified names like `moler.cmd.unix.ip_addr.IpAddr`...

## `get_cmd()`, `get_event()`, `get_observer()` Main focus is on `get_cmd` but same code modification should be made for `get_event` - for parity and because nested SM may also posses some events....

## `goto_state()` State in current moler SM implementation may be changed in 2 ways: 1. unconditionally 1. via `on_connection_made()` into `CONNECTED` state 1. via `on_connection_lost()` into `NOT_CONNECTED` state 1. via...

## device removal All devices have API `def register_device_removal_callback(self, callback)` and `def remove(self)`. Registration is used by `DeviceFactory`. Factory performs caching - when you call `get_device(name='DEV1')` next time and 'DEV1'...