Skip to content

Guide Overview

Comline takes a schema you write by hand and carries it through a fixed pipeline:

parse → resolve imports → validate → freeze → generate

Each stage has its own page in this guide; this is the map.

1. Writing a Schema

A project is a directory with a package manifest (config.idp) and one or more .ids Schema / IDL files under src/. The schema language defines structures, enums, protocols, errors and settings, with docstrings attached to any of them.

comline new my-api      # scaffold config.idp + comline.toml + src/main.ids

2. Checking and Compiling

comline check parses, resolves imports and validates.

comline build does that and then freezes the result: the schema becomes a set of immutable Intermediate Representation written into a Content Addressable Store, .comline/, as a new commit in an append-only chain.

Each build is recorded under a pre-release version leading to the next release; comline release creates that version, bumped by the largest change since the last one — see Versioning rules.

3. Generate code

comline generate turns the compiled schema into source for a target language. What languages a package supports is declared in config.idp; where the code lands and in what layout is the consumer's choice, in comline.toml. One schema history can be generated across several languages and several past versions at once.

4. Runtime

At run time a runtime library handles transport, message parsing and routing a protocol call to its implementation, over a pluggable call system (JSON-RPC, a compact binary framing, or your own).

Where things are owned

Concern File Owner Frozen into CAS
Schema shape, package identity, which languages are supported config.idp package author yes
Output location, layout, which versions to emit comline.toml consumer no

See Packages & dependencies for the manifest, and the Design section for the reasoning behind the split.