Service Specs

Service Specs

Service specs are .sidl files located in specs/services/. They declare what interfaces a service provides and what it depends on. serpgen uses these declarations to generate the appropriate C++ base classes, stubs, and constructor wiring.

Format

service:
  name: ClimateManager
  version:
    major: 1
    minor: 0
  type: generated   # generated | adapter | external | mock

implements:
  - IClimateManager

uses:
  - IClimateHal
  - IPersistenceService

Field Reference

service

Field	Description
service.name	Service name. Used as the class name and directory name in generated code.
service.version	Version of this service spec.
service.type	Generation mode — see below.

service.type

Controls what serpgen generates for this service.

Type	What serpgen generates
generated	Full base class and skeleton. You fill in the implementation by extending the generated stub. This is the standard mode for new services.
adapter	Transport adapter and proxy only. Use when you have an existing service you want to expose over IPC without regenerating its internals.
external	Proxy only (client side). No server-side code is generated. Use for services that exist outside this project and are accessed remotely.
mock	A mock implementation with configurable return values. Used in testing to stand in for real service dependencies.

implements

List of interface names this service provides. Each name must match the name field of an interface defined in one of the interface_dirs.

implements:
  - IClimateManager
  - IClimateStatusReporter

uses

List of interface names this service depends on. serpgen generates typed proxy references for each and injects them into the service constructor.

uses:
  - IClimateHal
  - IPersistenceService

Generated Code

For a service named ClimateManager with type: generated, serpgen produces:

gen/components/Climate/src/services/ClimateManager/
  IClimateManager.hpp          # Generated typed interface (abstract)
  impl/
    ClimateManagerBase.hpp     # Generated base class — handler registration, dependency wiring
    ClimateManagerBase.cpp
    ClimateManager.hpp         # Generated default stub — safe no-op implementations
    ClimateManager.cpp

Service Inheritance Chain

IClimateManager          (generated interface — abstract typed API)
       ↑
ClimateManagerBase       (generated — wires handlers, injects dependencies)
       ↑
ClimateManager           (generated default stub — override methods you need)
       ↑
ClimateManagerImpl       (your code — lives in src/, never overwritten)

Your implementation file lives in:

src/components/Climate/services/ClimateManager/
  ClimateManagerImpl.hpp
  ClimateManagerImpl.cpp

This file is generated once as a starting point if it does not exist, then never touched again. All business logic goes here.

Dependency Injection

For each interface listed in uses, the generated ClimateManagerBase constructor accepts a typed proxy reference. You never write this wiring — the deployment's generated main.cpp instantiates everything and passes the proxies in.

If ClimateManager uses IClimateHal and IPersistenceService, the generated constructor signature is roughly:

ClimateManagerBase(
    std::shared_ptr<IClimateHal> climateHal,
    std::shared_ptr<IPersistenceService> persistence
);

Related Pages

• Interfaces — interface contract format
• Deployment Specs — how services are assigned to processes
• Generated Code Layout — full directory layout of generated output