CHANNEL Documentation

RELv0.4.1.0 API1.0.0 TEST199 PASS

Documentation

Every page below is a file in the repository, rendered here from the same source — so what you read here and what you find on GitHub cannot drift apart. Each page also links to its original, in case you want the raw text.

Every page here is a file

This table is the whole of the documentation set: the repository path on the left, the page it becomes on the right. Build the site and the two are rendered from the same source, so a change to either side shows up on the other.

docs/ → site

README.mdProject README

docs/plugins/README.mdPlugin authoring guide

docs/plugins/CONVENTION.mdDevelopment convention

docs/plugins/MARKET.mdPublishing & discovery

turbo-plugin-js/README.mdWriting a JavaScript plugin

turbo-plugin-js/ARCHITECTURE.mdJS loader architecture

—Manifest reference

LICENSELicense (MIT)

docs/legal/THIRD-PARTY.mdThird-party components

docs/legal/PRIVACY.mdPrivacy

docs/legal/TERMS.mdTerms of use

Pages without a translation fall back to the other language and say so at the top.

Start here

The whole thing is one dependency, one config object, one submit call. Pause, resume, cancel, batch and diagnostics are on the same client.

Kotlin

// build.gradle.kts
dependencies {
    implementation("dev.turbodl:turbodl-core:0.4.1.0")
}

// Kotlin
val client = TurboClient(TurboConfig(maxConnectionsPerTask = 16))
val id = client.submit(DownloadRequest(url, File("out.bin")))
val result = client.await(id)

shell

java -jar turbodl-cli-all.jar <url> -o out.bin -c 64
java -jar turbodl-cli-all.jar <url> --json       # NDJSON
java -jar turbodl-cli-all.jar --batch tasks.txt  # one URL per line

turbodl --json · stdout

{"type":"start","url":"<url>","output":"out.bin"}
{"type":"timing","stage":"metadata","t_ms":184,"probe_ms":96,"resume":""}
{"type":"progress","state":"downloading","downloaded":222732288,"total":358411469,"percent":62,"speed":19503514,"connections":16,"eta_ms":7020}
{"type":"completed","url":"<url>","file":"out.bin","bytes":358411469,"sha256":"0f3a…"}
{"type":"summary","total":1,"failed":0}

The whole config surface

Nine fields, all public, all with a documented range. Nothing else is tunable at run time — the engine has no hidden knobs and no phone-home defaults.

TurboConfig

maxConnectionsPerTask16 · 1..256

maxConcurrentTasks3 · 1..64

globalSpeedLimitBytesPerSec0 = unlimited

maxRetries5 · 0..50, per segment

dynamicSegmentationtrue

tailAssist / tailAssistMinBytestrue · 2 MiB

overlapMerge / bufferedSegmentWritefalse · false

minSegmentSize / blockSize64 KiB · 16 MiB

proxy / dns / trustAllCertsDirect · System · Manual · PAC / System · StaticHosts · DoH

Values are the defaults in TurboConfig.kt; every one of them can be set per client.

What a plugin manifest looks like

A plugin is a JAR plus this file. The reference page lists every field, its type, whether it is required, and the allowed values.

turbodl-plugin.json

{
  "manifestVersion": "1.0",
  "id": "parser.example",
  "name": "Example parser",
  "description": "Turns example:// links into download requests.",
  "version": "0.1.0",
  "author": "you",
  "homepage": "https://github.com/you/turbodl-plugin-example",
  "license": "MIT",
  "category": "turbodl-parser",
  "capabilities": [
    "dev.turbodl.cap.parser"
  ],
  "protocols": [
    "example"
  ],
  "turbodl": {
    "apiMajor": 1,
    "requiredApiVersion": "1.0.0"
  },
  "entry": {
    "language": "kotlin",
    "pluginClass": "com.example.ExamplePlugin"
  },
  "extensionPoints": [
    "turbo.linkParser"
  ]
}

The same file the manifest reference renders, so the two pages cannot disagree.

Documentation

Project README

What TurboDL is, what it does, how to add it to a project, and the API surface — the repository's own README.

Read

Plugin authoring guide

How to write a plugin and get it loaded: the interfaces, the categories, and the lifecycle you must respect.

Read

Development convention

The compatibility rulebook: what counts as a stable API, how versions are negotiated, naming, and the safety rules a plugin may not bend.

Read

Publishing & discovery

There is no registry to sign up to. Plugins are discovered through a GitHub topic plus a manifest — this is the whole convention.

Read

Writing a JavaScript plugin

The `host`/`plugin` ABI, the three primitives everything is built on, and what a script is deliberately not allowed to do.

Read

JS loader architecture

Why the loader is shaped the way it is: runtime/context ownership, the unload sequence, and the host-side boundaries.

Read

Manifest reference

Every field of turbodl-plugin.json, generated from the JSON Schema that validates it.

Read

Terms & policies

License (MIT)

MIT, plus four supplemental clauses that keep plugins independent works. Verbatim, not summarised.

Read

Third-party components

Which libraries ship with TurboDL, under what license, and which projects supplied ideas without supplying code.

Read

Privacy

What leaves your machine when you use TurboDL — and the list of things that never do.

Read

Terms of use

Responsibility, warranty, third-party plugins, and the name — the parts a license does not spell out.

Read

Architecture

Three rules decide every design question in this project:

core works alone. turbodl-core is a complete engine with zero plugin dependency; plugins are strictly additive.
the kernel is only mechanism. It knows no protocol — lifecycle, cleanup, event bus, service registry, extension points, version handshake, diagnostics.
dependency direction is strict. runtime → core, never the reverse.