Skip to main content

Component Architecture Overview

FreeTAKServer uses a modular component system built on the DigitalPy framework. Components are self-contained units that handle specific CoT message types and business logic, allowing for extensibility and maintainability.

Component Types

Core Components

Core components provide fundamental FTS functionality and cannot be disabled. Location: FreeTAKServer/components/core/

Domain Component

Purpose: Core CoT domain model
  • Event, Point, Detail classes
  • CoT serialization/deserialization
  • Type mapping and conversion
  • XML/JSON parsing
Location: components/core/domain/

Type Component

Purpose: CoT type mapping
  • Machine ↔ Human readable type conversion
  • Type registration and lookup
  • Caching strategies
  • Memory/database mapping
Location: components/core/type/

XML Serializer Component

Purpose: XML serialization
  • Domain object → XML conversion
  • XML → Domain object parsing
  • Attribute mapping
  • Namespace handling
Location: components/core/xml_serializer/

CoT Parser Component

Purpose: CoT message parsing
  • XML parsing and validation
  • Element extraction
  • Error handling
  • Format detection
Location: components/core/cot_parser/

Extended Components

Extended components provide optional functionality that can be enabled/disabled. Location: FreeTAKServer/components/extended/

Component Structure

Each component follows a standard directory structure:

Component Elements

Maps action names to controller methods.
Component-specific domain model extensions.
Business logic and processing.
Public interface for the component.
Component constants and settings.

Component Lifecycle

Registration

Components are registered during FTS initialization:

Initialization

Processing Flow

Shutdown

Base Classes

CoTNode

All CoT domain objects inherit from CoTNode:
Features:
  • Tree-based data structure
  • Parent-child relationships
  • Attribute storage via cot_attributes dict
  • XML serialization support
  • Property-based access

CoTProperty Decorator

The @CoTProperty decorator marks attributes as CoT properties:
Purpose:
  • Mark serializable properties
  • Enable automatic XML generation
  • Support property introspection

Domain Controller

Base controller for domain operations:

Creating a Component

Step 1: Component Structure

Step 2: Define Action Mapper

Step 3: Create Domain Model

Step 4: Implement Controller

Step 5: Create Facade

Step 6: Register Component

Component Examples

Emergency Component

Handles emergency alerts and 911 calls: Location: components/extended/emergency/ Features:
  • Process emergency CoT messages
  • Track active emergencies
  • Broadcast to all users
  • Emergency cancellation

Mission Component

Manages mission packages and synchronization: Location: components/extended/mission/ Features:
  • Mission creation and management
  • Package upload/download
  • Mission subscription
  • Change tracking
  • Layer management

Track Manager Component

Tracks position history and movement: Location: components/extended/track_manager/ Features:
  • Position history storage
  • Track playback
  • Dead reckoning
  • Stale position cleanup

Best Practices

  • Single Responsibility: Each component handles one specific domain
  • Loose Coupling: Components communicate via action mapper
  • High Cohesion: Related functionality grouped together
  • Dependency Injection: Use ObjectFactory for dependencies
  • Cache frequently accessed data
  • Use database connection pooling
  • Implement rate limiting for high-volume components
  • Profile and optimize hot paths
  • Use async operations where appropriate

Architecture

Understand FTS architecture

Services

Learn about FTS services

CoT Messages

Understand CoT format

Development Guide

Component development guide