Transition to the Component-Based Model

[DmitryAstafyev]

These changes involve a fundamental shift in the application's architecture regarding embedded parsers and data sources.

Problem Statement

Currently, every parser or source is represented as a variant in a common enum. As a result, all related types (such as settings, options, etc.) become part of the core application and propagate to higher layers. This significantly reduces flexibility. For example, adding or removing a parser/source requires modifying dozens of modules across the application.

Solution (Basic Description)

• Introduce the concept of a “component,” which can represent either a parser or a data source (with potential for future extension).
• All fixed enums for parsers and sources are removed.
• Sessions are now created using a set of components.

Outcome

• Parser and source implementations become isolated.
• Changes to any individual parser or source no longer affect the core or higher-level layers of the application.

Chipmunk as a service

One more important motivation point is: this refactoring will allow delivery chipmunk as a tiny service in a way - "only necessary coverage". In other words, if we need DLT tracking service, we can easily remove all unrelated stuff (serial, commands, SomeIp, etc.) and delivery dlt-chipmunk service as well.

Of course, that's also a huge cleanup of the API, which is very important from a service perspective. Stability of API (non-sensitive to supported components) will allow us to wrap the core into an executable service without pain.

Upgrade / refactoring roadmap

Design

• Text-file use case. Makes sense to skip parsing of text file (like with master solution), but that part currently isn't implemented

Core

• Remove type-targeted API. For example, any API related directly to DLT or SomeIp
• Implement cancel-safe on LogRecordWriter to keep MessageProducer cancel-safe as well
• Propagate changes to plugins
• Replace plugin's options scheme with component's options scheme
• Restore tail feature
• Restore SDE channel
• Check compatibility of LogRecordWriter with databases

Electron layer (ts-binding, electron, platform)

• Remove any refs to Observe object
• Remove type-targeted API. For example any API related directly to DLT or SomeIp
• Cleanup IPC (electron - client)

Client

• Remove any refs to Observe object
• Restore the manager of active and recent observation operations (allows start/restart/stop current operation).
• Restore history module (stored recent action information)
• Restore the controller of recent inputs (allows fill option fields with recently used input)
• Update API to delivery the right session description (titles of session tabs)
• Update a way of automatic detecting of parser/source for given file's type.
• Update home screen and file's type related links (it should come from core now based on a list of available components; for example if DLT parser doesn't exist - there are should be menu-item - "Open Dlt File"). Also plugins should be considered as well in this context.

Tests

• Add general tests for components in core. It should be abstract tests, which take the available component and try it out in all possible combinations. It looks like it would require to have for each component descriptor also test descriptor or something like that
• Remove all Observe object related tests

[marcmo]

then please also name it Registry, not Components

[marcmo]

if we distinguish between Parsers and Sources (as we should do) it makes no sense to introduce an Entry type.
just store it it

• parsers
• sources
  in 2 different hashmaps